Hallo,
gibt es einen Grund unter Neutrino die Anzahl der Ringpuffer nicht auf 99 zu stellen ?
(Ausser dem Ramverbrauch ?)
Ich habe irgendwo mal gelesen der könnte sich selbst überschreiben.
Ich dachte aber wenn er sich selbst einholen sollte wird abgebrochen und ein neues File angelegt oder ?
Danke
Bye
PetB
Optimale Anzahl der Ringpuffer
-
- Erleuchteter
- Beiträge: 785
- Registriert: Samstag 6. August 2005, 03:39
-
- Oberlamer, Administrator & Supernanny
- Beiträge: 10532
- Registriert: Samstag 13. Juli 2002, 10:49
Es geht dabei "nur" um den Speicherverbrauch - je mehr sonst noch auf der Box läuft (tuxmaild, tuxtxt-caching, sectionsd *scnr*), um so knapper ist der Speicher nunmal.
"Überschreiben" kann sich der Puffer nicht, außer er wäre fehlerhaft programmiert.
Edit: ich hab nochmal einen Blick in den Quellcode geworfen - ein Ringpuffer braucht 68056 Bytes, bei 99 Puffern werden also 6737544 Bytes (ca. 6,4MB) verbraten.
"Überschreiben" kann sich der Puffer nicht, außer er wäre fehlerhaft programmiert.
Edit: ich hab nochmal einen Blick in den Quellcode geworfen - ein Ringpuffer braucht 68056 Bytes, bei 99 Puffern werden also 6737544 Bytes (ca. 6,4MB) verbraten.
There are 10 types of people in the world: those who know binary and those who don't
-
- Senior Member
- Beiträge: 1339
- Registriert: Donnerstag 24. April 2003, 12:12
Bei 99 werden zwar 6737544 Bytes angefordert, tatsächlich benutzt werden aber 8388608.
Der verwendete Ringpuffer-Code ist auf Puffergrößen im Zweierpotenz-Bereich ausgelegt und rundet im Bedarfsfall auf, hier werden also 2^23 Bytes reserviert.
Das heißt auf deutsch: die angebotene Granularität von 20-99 wird auf genau 3(!) Puffergrößen umgesetzt:
20...30 = 2097152 Bytes
31...61 = 4194304 Bytes
62...99 = 8388608 Bytes
Zugegeben ist es ungünstig vom Ringpuffer-Code, einen fein unterteilbaren Parameter zu exportieren, der intern viel gröber ausgewertet wird. Nicht jeder möchte erst stundenlang anderer Leute Code analysieren bevor er ihn benutzt (nein, er kommt nicht vom Tuxbox-Projekt).
Es wäre vielleicht sinnvoll, die "Anzahl der Ringpuffer" (eigentlich müßte das ja eher "Tiefe" bzw. "Größe" des Ringpuffers heißen) auf 3 Einstellungen zu reduzieren.
Der verwendete Ringpuffer-Code ist auf Puffergrößen im Zweierpotenz-Bereich ausgelegt und rundet im Bedarfsfall auf, hier werden also 2^23 Bytes reserviert.
Das heißt auf deutsch: die angebotene Granularität von 20-99 wird auf genau 3(!) Puffergrößen umgesetzt:
20...30 = 2097152 Bytes
31...61 = 4194304 Bytes
62...99 = 8388608 Bytes
Zugegeben ist es ungünstig vom Ringpuffer-Code, einen fein unterteilbaren Parameter zu exportieren, der intern viel gröber ausgewertet wird. Nicht jeder möchte erst stundenlang anderer Leute Code analysieren bevor er ihn benutzt (nein, er kommt nicht vom Tuxbox-Projekt).
Es wäre vielleicht sinnvoll, die "Anzahl der Ringpuffer" (eigentlich müßte das ja eher "Tiefe" bzw. "Größe" des Ringpuffers heißen) auf 3 Einstellungen zu reduzieren.

Zuletzt geändert von Npq am Samstag 19. November 2005, 11:58, insgesamt 1-mal geändert.
-
- Oberlamer, Administrator & Supernanny
- Beiträge: 10532
- Registriert: Samstag 13. Juli 2002, 10:49
OK, ich hab nur im stream2file.cpp nachgesehen, den Code für den Ringbuffer selber hatte ich seinerzeit "ungesehen" vom Movieplayer geklaut 
Die Änderung der Settings wären an der Stelle sicher sinnvoll, wenn sich das so wie von Dir beschrieben verhält.

Die Änderung der Settings wären an der Stelle sicher sinnvoll, wenn sich das so wie von Dir beschrieben verhält.
There are 10 types of people in the world: those who know binary and those who don't
-
- Erleuchteter
- Beiträge: 785
- Registriert: Samstag 6. August 2005, 03:39
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
...dafuer ist die variable Ringpuffergroesse ja auch eingerichtet worden und die funktioniert Bestens. Vorher sollte man aber imo versuchen das Netzwerk zu optimieren und wenn dann nix mehr zu verbessern ist und immer noch Abbrueche auftreten eben die Ringbuffergroesse sinnvoll erhoehen. Ein Allheilmittel ist das nicht und bei lange anhaltendem hohen Traffic versagt das wegen der mangelnden Resourcen der Dbox ebenso.petb hat geschrieben:Ich glaube nämlich das ich damit bessere Aufnahmeergebnisse erziele.