Auslöser für pl (packet lost) mit ggrab?

[hugohuetzel]

Seit einigen Wochen habe ich vermehrt "packet lost's" beim Streamen min ggrab (upd). Es gehen meistens so um die 20 Packete (meistens alle auf einmal) pro Film verlohren. Seit ich das neue cramfs vom 19.05. drauf habe sind es sogar um die 200 pro Film.
Als Streaming-Server benutze ich einen P4 mit 2GHz und 512Mb (sollte also eigentlich ausreichend sein).
Durch was kann so ein "pl" entstehen?
Hat jemand ähnliche Probleme?

[petgun]

Hi,

...Seit ich das neue cramfs vom 19.05. drauf habe sind es sogar um die 200 pro Film...

..hast Du den BH-Mode eingeschaltet und wie laeuft's ohne UDP-Unterstuetzung ?

cu,
peter

--
Beer kills brain cells, but only the weak ones.

[tonsel]

Paket-Verluste bei UDP können u.a. durch Festplattenzugriffe auf dem Streamingrechner erzeugt werden (z.B. automatische Defragmentierung, Auslagerungsdatei, ...)

tonsel

[hugohuetzel]

Ohne UDP oder BH-Mode habe ich leider sehr viele resyncs.
Im Februar und im März hatte ich mit dem Gandalfx-Image vom 18.02. absolut keine Probleme.
Seit April habe ich (immernoch mit Image vom 18.02.) immer wieder diese pl's und die Abbrüche (waiting for data...) kommen dann auch immer öfter. Wenn ich dann neu Flasche sind wenigstens die Abbrüche eine zeitlang weg.

Ich habe übrigends eine Nokia-Kabel mit 2xI und Avia600.
Streaming-Server P4 2GHz 512Mb Debian-Linux.

[hugohuetzel]

Paket-Verluste bei UDP können u.a. durch Festplattenzugriffe auf dem Streamingrechner erzeugt werden (z.B. automatische Defragmentierung, Auslagerungsdatei, ...)

An den pl's ist also immer der Streamingrechner schuld?
Dann verstehe ich nicht warum ich seit dem Image vom 19.05. ca. 10x so viele pl's habe wie davor (Wobei die Aufnahme mit 20 pl's natürlich genau so verhunzt ist wie mit 200 ).
Ich habe gestern mal ein bischen mit hdparm herumgespielt. Mal schauen wie die nächste Aufnahme klappt.

[petgun]

hi,

Ohne UDP oder BH-Mode habe ich leider sehr viele resyncs.
Im Februar und im März hatte ich mit dem Gandalfx-Image vom 18.02. absolut keine Probleme.
Seit April habe ich (immernoch mit Image vom 18.02.) immer wieder diese pl's und die Abbrüche (waiting for data...) kommen dann auch immer öfter..

..und an Deinem Rechner/Netzwerk hast Du nichts geaendert?

Wenn ich dann neu Flasche sind wenigstens die Abbrüche eine zeitlang weg

ist schon komisch...ich habe allerdings auch den Eindruck, das es die letzten Wochen mit dem Streaming nicht mehr so gut klappt....??

Vielleicht Fruehjahrsmuedigkeit?

cu,
peter

[tonsel]

Normalerweise ist für UDP-Verluste immer der Streaming-Rechner verantwortloch. Andernfalls würde das ja bedeuten, dass die DBox die Pakete gar nicht abschickt, was ich für unwahrscheinlich halte.

Es könnte allerdings sein, dass sich beim Imagewechsel mit dem Sende-Timing etwas verändert hat, wodurch die Paket leichter verloren gehen. Bei mkdvd habe ich aber auch schon mit fast 10 MBit/s gesendet, ohne dass Pakete verloren geangen sich (AMD K6-2 300).

tonsel

[hugohuetzel]

Mit den überarbeiteten HD-Einstellungen (mit hdparm) hatte ich gestern keine pl's mehr. Lag also am Streamingserver.
Dafür hat sich die Box nach einer Stunde aufgehängt. Ich hoffe mal das das ein einmaliger Ausrutscher war .

[petgun]

Hi,

Mit den überarbeiteten HD-Einstellungen (mit hdparm) hatte ich gestern keine pl's mehr. Lag also am Streamingserver.
Dafür hat sich die Box nach einer Stunde aufgehängt. Ich hoffe mal das das ein einmaliger Ausrutscher war .

was hast Du denn da genau 'optimiert' ? Ich verstehe nicht wieso Du ohne UDP-Unterstuetzung so viele (mehr) Resyncs hast....sind die jetzt auch zurueckgegangen nach Deiner Optimierung mit hdparm?

cu,
peter

--
"It's not enough to succeed. Others must fail"
[Gore Vidal]

[hugohuetzel]

@petgun

Da hast Du (glaube ich) etwas falsch verstanden.
Ich hatte (und habe ) mit UDP keine Resyncs. Mit UDP bricht die Aufnahme entweder komplett ab (timeout wayting for data...) oder ich hatte eben diese verlorenen Pakete (pl's).
Ohne UDP (TCP) habe ich laufend Resyncs, da die Prozesor-Last auf der Box beim Streamen durchgegend bei 100% liegt. Dafür können mit TCP keine Pakete verloren gehen, da TCP ein verbindungsorientiertes Protokoll ist.

Optimiert habe ich die Treiber-Einstellungen:

hdparm -d1 -u1 -m16 -c3 /dev/hda

-d1: DMA einschalten
-u1: unmaskirq einschalten
-m16: multiple sector count 16
-c3: I/O support = 32-bit w/sync

Siehe http://linux.oreillynet.com/pub/a/linux ... tml?page=1

[petgun]

Hi,

Ich hatte (und habe ) mit UDP keine Resyncs. Mit UDP bricht die Aufnahme entweder komplett ab (timeout wayting for data...) oder ich hatte eben diese verlorenen Pakete (pl's).
Ohne UDP (TCP) habe ich laufend Resyncs, da die Prozesor-Last auf der Box beim Streamen durchgegend bei 100% liegt.

warum UDP, ist mir schon klar....die 100% CPU-Last auf der BOX ohne UDP sind aber nicht normal...seit den Modifikationen von Gandalfx und Obi (BH-Mode) ist das kein Thema mehr.

cu,
peter

[hugohuetzel]

Ich habe das jetzt nochmal überprüft.
100% cpu habe ich nur ohne Gandalfx-Mod.
Mit Gandalfx habe ich so um die 50% bei UDP und 60%-80% bei TCP.

Ich habe auch schon eine Idee warum ich mit TCP immer Resyncs bekommen habe: Warscheinlich hatte ich mit TCP genauso pl's wie mit UDP. Durch das erneute Senden der Packete wurde dann vermutlich die CPU zu stark belastet (100%).

Woher kommt eigentlich der "waiting for data" Fehler (mit UDP)?
Ich dachte für UDP sei ein workaround drin.

[Gandalfx]

@hugohuetzel
Also, ich vermute, an deinem Netz/Rechner ist irgendwas schief. Normalerweise sollte ein 2 GHz-Rechner keinerlei Probleme haben. Unter Linux hab ich überhaupt noch keine Packet-Loss gehabt. Weiterhin ist eigentlich nur bei sehr hoher Last, sagen wir ab 7000 kBit/s ein wirklicher Vorteil bei udp. Wenn du bei "normalen" Datenraten unter 5000 kBit/s Resyncs hast, deutet das auch auf ein Problem beim Rechner/Netz hin.

Bei udp "waiting for data" hab ich keine Idee, der Workaround funktioniert eigentlich...

[hugohuetzel]

Ich denke das ich das Problem mit meinem Streamingserver gefunden habe.
Einer meiner Screensaver (xscreensaver) verbraucht den gesammten Speicher. Warscheinlich einer der GL-Screensaver.
Ich konnte es bisher noch nicht ausgiebig testen, aber ich denke das es das war.

Danke nochmals an alle