Resyncs und prinzipielle Lösung hierzu

[cgill]

Hallo liebe Gemeinde,

Nachdem das Resyncprob unter der alten Software gelöst ist ;-) wollen wir doch unser geliebtes Linux nicht aus den Augen verlieren.
Das Prob mit den Resyncs ist wohl, das die Daten irgendwie schneller kommen als man diese senden kann. Oder umgekehrt nicht schnell genug abgeholt werden, so daß Pakete verschluckt werden.

Meine Grundidee zur Lösung wäre folgende:

1. Man lege im Memory der Box 2 Puffer an (möglichst groß).
2. Man nehme 2 parallel laufende Threads
a.) der eine schaufelt die ankommende Daten immer in die beiden Puffer zuerst in Puffer 1 bis dieser voll ist dann in Puffer 2 dann wieder 1 usw.
b.) der zweite Thread schaut nach ob einer der Puffer voll ist und sendet ihn an den PC.

Was gewinnt man nun dadurch.

1. Der Aufwand zum versenden wird geringer. Man muß nicht mehr viele kleine Pakete versenden sondern weniger große. Die eigentliche Datenmenge bleibt zwar (abzgl. Overhead gleich) aber dennoch müsste dies der Performance zuträglich sein. Tausch ich z.B. via FTP Dateien aus komme ich auf eine reine Performance von >8MBit pro Sekunde. Diese Bitraten kommen wohl bei keinem Stream vor.

2. Die Zeit die ein Paket laufen kann wird größer, winzige Pausen (PC kann mal eben nicht) dürften sich nicht mehr so fatal auswirken wie bisher.
3. Die minimale Zeit zwischen 2 Paketen ist nicht mehr so entscheidend sondern eher die durchschnittliche Zeit innerhalb eines gewissen Zeitraums. Das hat insbesondere im Grenzbereich deutliche Vorteile.

Was haltet ihr von dieser Idee ?
Ich weiss es ist hinreichend eklig zu implementieren weil es bedeutet auf der Box und am PC grundlegendes zu ändern. Aber denke es wäre ein Erfolg versprechender Weg.

[Gandalfx]

Hallo
das ist nicht der Grund für die Resyncs. Es ist dort schon ein 1 MB Puffer drin. (Der reicht also für eine Größenordnung für 10s bei 10% Überlast). Es werden immer 16KByte auf einmal Richtung Netz geschrieben. Hier gibts imho wenig bis nichts mehr zu optimieren.

Gründe für die Resyncs sind:
1. Prozessorlast zu hoch (die offiziellen Images haben ca. 100 % Prozessorlast bei ca. 5500 kBit/s. (Beim modifizierten Image sind es nur noch < 50 %, und dort sind (fast) keine Resyncs mehr bis ca. 8000 kBit/s.
2. Treiberfehler
3. Netz dicht bei sehr hohen Datenraten. Abhilfe hier: udp
4. DMX-Pufferüberlauf (führt zum Streamabbruch) durch einen Softwarebug (Blockiert das Schreiben) im Netzwerktreiber (noch nicht gefunden). Abhilfe: mit udp streamen, dort ist ein Workaround drin, der bei einer Blockierung den socket schließt und wieder öffnet, dann gehts weiter.
5. Hintergrundlast bei Windoof (Ich habe Paketverlust bei udp, wenn ich nur das Fenster vom Grab-Programm beweg (Ist halt nur ein 2200er ;-))

[lawww]

hi,

ich häng mich hier mal rein, da mich das streamen auch gefesselt hat.

in wie weit 2 puffer hier besser sind als einer vermag ich nicht zu sagen, glaube gandalfx aber, dass hier nichts mehr zu holen ist, er hat sich immerhin ausgiebig damit beschäftigt...

punkt 5 kann ich allerdings nicht bestätigen! hab selber hier nur nen 1400er amd laufen, p2p, stündliches defrag, diverse tasks und dienste im hintergrund am laufen, trotzdem, was auch immer ich mache, hier lassen sich keine resyncs provozieren, selbst bei parallelem brennen, surfen, divx abspielen nicht!
punkt 4 ist mir mir noch nicht aufgefallen - hoffentlich bleibt's so.
3 ??? moment mal, wenn kann nur die dbox ihren netzabschnitt dicht machen, dann kommt der switch und ein mindestens 100mbit fullduplex netz (wenigstens bei mir und sicherlich bei den meisten hier), sowohl switch als auch alles dahinter sind wohl nicht annähernd ausgelastet (ebenfalls vermute ich das bei den meisten hier - bei mir garantiert).
was bleibt sind 1 und 2! 2 kann ich nicht beurteilen, da bin ich nicht tief genug in der materie, 1 ist aus meiner sicht sehr wahrscheinlich:
ich habs schon in anderen beiträgen erwähnt: onhe sectionsd und playback lassen sich die resyncs schon minimieren, meist ganz vermeiden, wenn dann die box noch frisch aus nem deep-standby kommt, habe ich überhaupt keine resyncs mehr. laeuft sie allerdings schon ein paar stunden und oder kommt aus dem normalen standby, kommt es hin und wieder zu problemen.
ich habs noch nicht via top beobachtet, aber ich schätze, irgend welche prozesse fressen sich in den speicher und / oder die cpu. damit wird's dann zu eng für den stream-prozess.
alle die ständig probleme haben: schaltet mal playback und sectionid bei der aufnahme aus und programmiert die dbox auf aufnahme, fahrt dann in den deep-standby. mich würde mal interessieren, ob eure probleme dann bei der aufnahme auch weg sind.
@gandalfx: mit deinem mod ist mir die box ständig abgeschmiert, ich werd's aber nochmal versuchen, die last-ersparnis von ca. 50% will ich auch!!! weißt du, ob's mit deiner version des 5.3. images und baseimage 1.6.8 auf ner sagem 1xi kabel bekannte probleme gibt???

grüße lawww

[lawww]

also: das mit den 50% passt! da hab ich auch mit playback keine resyncs.

nur leider schmiert mir mit deinem mod die box beim zappen in kürzester zeit ab
((
gibt es ne besonders zu empfehlende versionskombination mit deinem mod?

danke schonmal im voraus

lawww

[cgill]

Sorry für den dummen Ansatz von mir.
Hätte mir denken können das ihr Cracks schon auf diese Idee gekommen seid.
Bin ein wenig aus dem Thema weil ich mich seit ca. 6 Monaten nicht mehr mit dem Thema beschäftigt habe. Das mit dem modifizierten Inage klingt interessant.
Ich bin jetzt umgezogen, habe im kompletten Haus neue Kabels verlegt und kann jetzt endlich auch ständig auf die D-Box via Netz zugreifen.
Von der Verkabelung sieht es so aus, das die Box von den Rechnern her gesehen hinter einem 100er Switch hängt der gleichzeitig DSL-Router ist.
Ich denke ich muß mich erst mal wieder in die Thematik einlesen.
Könnte mir jemand vielleicht ein gutes Streaming-Image empfehlen. (Habe immer noch das gute alte von letztem Jahr drauf.) Ach ja ich hab ne Sagem 1xI Kabel-Box.

[lawww]

die box hab ich auch, gandalfxs image läuft bei mir leider keine 10 minuten, allerdings ist beim streamen die last echt extrem niedrig.

übrigens bleibt die box per ftp und telnet erreichbar. lediglich die fernbedienung steigt aus! bild und ton bekommt man schon per http (zapit?stopplayback -> zapit?startplayback) wieder zum laufen! umschalten via http funktioniert scheinbar nicht. rc bleibt tot! hmm: selbst reboot via telnet ignoriert sie... dafür ist die cpu zu über 90% idle ;-)

bei mir läuft bisher das aktuelle cdk (alexW) mit baseimage 1.6.8 recht gut, allerdings streamen unter den oben genannten einschränkungen, und mit etwa einem hänger pro tag...

lawww

[tonsel]

@cgill

Genau nach diesem Prinzip arbeitet mkdvd (http://www.haraldmaiss.de). Der Erfolg ist, dass man die "Avia GT-DMX Bufferoverflows" beseitigen kann. Diese waren bei mir für ca. 90% der Resyncs verantwortlich.

Resyncs die auf Empfangsprobleme, irgendwelche Treiberfehler ö.ä. zurückzuführen sind, kann man damit nicht bekämpfen.

tonsel

[Gandalfx]

@lawww
Du kannst nur das modifizierte Image vom 5.3 probieren. Bei alexw gibts bei meiner Modifikation auch Hänger beim Zappen, zwar seltener (auch Sagem). Deshalb ist die Sache auch nicht im offiziellen Image. Bei meiner Philips läufts gut. Deshalb finde ich das Problem auch nicht.

Noch mal zur Netzlast: Auf der Halbduplex-Leitung zur Box können je Nach Timing-Konstellation die Quittungs-Pakete vom Rechner zu Kollisionen und damit zu Paketwiederholungen und noch höherer Last führen.

@cgill
Probier mal mein modifiziertes vom 18.2. oder vom 5.3. Wenn sich sie Hänger beim Zappen in Grenzen halten, ists prima.
http://webmail.mw-itcon.de/ggrab/mtd2-180203.img

http://dboxupdate.berlios.de/files/gandalf.cramfs


Nochmal insgesamt meine Erfahrungen bisher:
90% der Resyncs gingen bei mir auf Konto der CPU-Last.
10% bleiben (Treiber, Übertragungsfehler, ...)

Ich scheine zu verkalken ;-) : der avia_gt_dmx-Puffer-Überlauf wird dadurch verursacht, daß die Routine zum Ausräumen des Puffers im normalen Prozesskontext läuft. Dieser hat (hardwaremäßig) eine Größe von 64K. Wenn ich einiges an Prozessorlast auf der Box habe, ist die Latency hier zu hoch (gemessen oft hier ca. 150 ms). Dabei läuft der Puffer über. Dieses läßt sich beseitigen, wie Tonsel es macht: alles stoppen, was nicht notwendig ist, oder durch meine Modifikation, wo dieses in einem anderen Kontext läuft.

Der Puffer-Überlauf,den ich meinte, ist der dmxdev-buffer-overflow. Dieser tritt beim mir selten auf, ist aber insgesamt vom Timing und Daten abhängig. Wenn ich die Puffergröße auf der Box ungünstig wähle, läßt sich der binnen Sekunden reproduzieren. Aber nochmal, dieses ist keine Überlast, sondern der write-Aufruf zum Schreiben auf die TCP-Verbindung blockiert für immer! Infolgedessen läuft der Puffer über.

Btw: wennn jemand diese Fehlermeldungen noch nicht gesehen hat, liegts eventuell nicht daran, daß der Fehler nicht auftritt, sondern daß in den meisten Images die Fehlermeldung ausgeschaltet ist ;-)

[leth]

@ GandalfX

Mit deinem Mod vom 05.03.2003 hab ich auch Probleme, wenn ich allerding die Version vom 18.02.2003 benütze, dann läuft die Box ohne Probleme. Hab sie so seit ca. 2 Wochen am Laufen, ohne größere Schwierigkeiten.

Komischerweise musste ich feststellen, dass es einen Unterschied macht, welches Image ich flashe bevor ich auf Deine Version vom 18.02.2003 update. Prinzipiell benütze ich immer das BI 1.6, da dies am stabilsten läuft. Wenn ich AlexW vom 18.02.2003 flashe und dann update hab ich sofort Hänger. Wenn ich jedoch AlexW's berühmten Snapshot vom 01.09.2002 flashe und dann auf Deine Version vom 18.02.2003 update, hab ich am wenigsten Probleme. Erklären kann ich mir das allerdings nicht

Resyncs hab ich miot dieser Kombination keine. Ich hab sogar schon Direkt Filme mit allen drei Audiokanälen ohne Resync gestreamt zB Vanilla Sky, Oceans Eleven, The Timemachine.

Cu leth

[grubi]

5. Hintergrundlast bei Windoof (Ich habe Paketverlust bei udp, wenn ich nur das Fenster vom Grab-Programm beweg (Ist halt nur ein 2200er ;-))

Verstehe ich nicht.
Ich habe ggrab über cygwin auf einem P3 800Mhz unter WinXp/Sp1 laufen und die CPU Auslastung beim streamen beträgt ca. 8%. Ob ich nebenbei auf dem Rechner eine DVD abspiele oder andere Sachen mache hat auf ggrab scheinbar keine Auswirkungen (TCP Modus). Will sagen - habe nur die DBox seitigen Probleme die ich mit nativen Windows grabbing Programmen auch habe.

Gruß,
Grubi.

[cgill]

Hmm, jetzt versteh ich langsam nichts mehr.

Gandalfx sagt die Syncs kommen von hoher Prozessorlast der Box.
Frage 1:
Daraus folgt doch eigentlich, daß man ein neues Image braucht. Oder ?

Frage 2:
Auf jeden Fall soll streamen via UDP besser sein. wie bekomme ich raus ob mein Image das unterstützt ?
(Image ist noch von Oktober letztes Jahr. Glaube Alew 1.6 (bin mir aber nicht sicher muß ich zu Hause noch mal nachsehen))

Frage 3:
tonsel sagt bei ihm hätte ein Alternatives Aufnahme Programm schon gewirkt (+ unnötige Tasks bei der Box nicht gestartet.)
Würde daher gerne zuerst mal nur mit dem PC anfangen. Zur Zeit hat der bei mir Windows (Win 98) drauf. Kann da auch eigentlich alles platt machen. Würdet ihr mir raten es erst mal mit Win98 und Cygwin zu versuchen oder soll ich erst mal Linux (oder anderes Windows) installieren. (Kenne mich mit Linux noch null aus daher würde ich eigentlich Windows vorziehen.)

Frage 4:
@tonsel Welche Tasks bei der Box sind bitte schön nicht notwendig. Gibt es irgenwo eine Aufstellung der Tasks mit Bedeutung ?

Frage 5:
@tonsel benutzt du die Box auch noch zum Fernsehen oder nur zum streamen. (sollte bei mir beides tun)

[tonsel]

@cgill

1) Die notwendigen Tasks kannst Du ermitteln, wenn Du die Yadd von

tonsel.xyz-soft.de (ohne .www!)

bootest. Im COM-Terminal vom Windows-Bootmanager mit "ps xa" die Task-Anzeige starten.

2) Ich benutze die Box praktisch nur zum Streamen - zeitgesteuert über Nacht. Bei mir ist im Flash die BN2.01. Ich nehme i.d.R. alle neuen Premiere-Filme auf DVD-RW auf und schau sie mir dann auf meinem DVD-Player an. Das hat bei mir auch den Vorteil, dass der AC3-Ton ohne Aussetzer funktioniert.

zu UDP:
wird bei mkdvd standartmäßig benutzt. Der Paketverlust unter Windows wir hierbei durch ein eingens Übertragungsprotokoll abgefangen. Ebenso die Netzwerkhänger.

tonsel

[Gandalfx]

@cgill
1. Ja, mit der Imagemodifikation geht die Prozessorlast auf der Box mächtig runter+keine Overflows mehr. Alternativ stoppt man alles auf der Box, was nicht unmittelbar notwendig ist, einschließlich der Bildwiedergabe. -> siehe tonsel

2. udp bringt was bei sehr hohen Datenraten > 8000 kBit/s und bei ungünstigen Timing-Bedingungen. Oder anders gesagt, es bringt das Tüpfelchen auf dem i ;-) . Unterstützt wirds ab Image vom 18.2.

3. Jede alternative Konstellation bedingt ein bischen anderes Ergebnis. Je nach Sender, Aufnahmeprogramm, Netzwerk, Rechner, Boxtyp gehts mal besser, mal schlechter. Win98 ist prinzipiell möglich (max. Dateigröße 4G). Wenn du ein sauber laufendes win98 hast, sollte das der kleinste Problempunkt sein.

Insgesamt liegen die Hauptprobleme auf der Box. Sehr weit kommt man nicht, wenn man nur den PC optimiert.

Tonsel stoppt eigentlich fast alles an Applikationen (Bildwiedergabe, sectionsd, httpd usw.) um die Overflows uzu vermeiden.

Das Einfachste ist eigentlich, das neue Image zu nehmen. Falls es nicht so gut läuft, kann man ja jederzeit innerhalb von Minuten zurück.

@grubi
Bei udp werden die Daten verworfen, wenn der rechner sie nicht schnell genug abholt, bei tcp wird die Box beim Senden kurzzeitig ausgebremst.

@leth
Mit der Reihenfolge der Updates hab ich auch keine Erklärung... Die Rückmeldung, daß das Image vom 5.3. schlechter läuft, hab ich auch schon von ein paar Leuten. Kann leider nichts finden (wenn ich ehrlich bin, habe ich auch im Moment keine Zeit ;-) ), bei mir läufts gut...

[grubi]

@cgill
@grubi
Bei udp werden die Daten verworfen, wenn der rechner sie nicht schnell genug abholt, bei tcp wird die Box beim Senden kurzzeitig ausgebremst.

Wer verwirft die Pakete ?
Die Box / oder UDP Protokoll des Rechners ?
Habe bei UDP unter Windows nämlich ständig wachsende Anzahl PL
(-debug). Ist bei TCP nicht der Fall.

[Gandalfx]

@grubi,
das mein ich....
der IP-Stack von Windoof macht das. Da läuft intern ein Puffer voll, und dann wird weggeworfen. Kann auch ein Seiteneffekt von cygwin sein. Unter Linux läufts immer stabil ohne Packet-Loss. Bei tcp kann das nicht vorkommen, wenn dann der Rechner zu langsam ist, wird von tcp (über die Quittungen) ausgebremst..

[grubi]

@grubi,
das mein ich....

Jetz hab ich es verstanden. Danke.