Streamabbruch, Ruckler bei Wiedergabe, Lösungsversuch

Digital Recording
new.life
Erleuchteter
Erleuchteter
Beiträge: 797
Registriert: Sonntag 19. Februar 2006, 01:17

Beitrag von new.life »

und die beiden Werte..
Synchrones Schreiben (O_SYNC): ein
Synchrones Schreiben (datasync): ein
stehen nach meinen Erfahrungen/Messungen besser auf 'aus'.
NASeweiss
Einsteiger
Einsteiger
Beiträge: 101
Registriert: Mittwoch 25. Oktober 2006, 14:36

Beitrag von NASeweiss »

in der Tat - vergesse immer, dass es ja jetzt IDE-User gibt 8)
fullcane
Einsteiger
Einsteiger
Beiträge: 110
Registriert: Dienstag 4. Oktober 2005, 23:21

Beitrag von fullcane »

@NASeweiss

vielen Dank! r/wsize 32768 war wohl der entscheidende Tipp!

Gruß
fullcane
fullcane
Einsteiger
Einsteiger
Beiträge: 110
Registriert: Dienstag 4. Oktober 2005, 23:21

Beitrag von fullcane »

Wahnsinn! Damit geht bei mir jetzt sogar Wireless Streaming. Ich bin begeistert!

Gruß
fullcane
Arbitrated_Loop
Interessierter
Interessierter
Beiträge: 24
Registriert: Sonntag 24. Oktober 2004, 19:43

Beitrag von Arbitrated_Loop »

Sorry, für die wahrscheinlich völlig bescheuerte Frage, aber wo genau muss ich den Parameter r/wsize=32768, udp einstellen ?
Irgendwie bin ich blind.

Der Parameter gilt doch auch wenn ich per NFS streame, richtig ?


EDIT: Oje, vergesst die peinliche Frage....Hab's gefunden. Wer lesen kann.....
capri
Interessierter
Interessierter
Beiträge: 53
Registriert: Dienstag 4. Juni 2002, 12:26

Ergbenis NFS Speedtest ist zum Movieplayer unterschiedlich

Beitrag von capri »

Hallo!

Das NFS Speedtest-Script von essu hat mir ziemlich geholfen - jedenfalls konnte ich damit meine Pufferprobleme einigermassen in den Griff kriegen.
Komisch ist nur das das Ergebnis vom Script mir gute Performance mit dem Protokoll UDP zeigt - dies aber beim Movieplayer ein mieserables Ergebnis bringt.

Hier das Messergebnis:

WinXP, SFU, Intel100 NIC -> 3Com Switch -> Allnet Switch -> Dbox2 AV600


udp, sync
3390
8126
192.168.2.6:/filme on /mnt/filme type nfs (rw,sync,v3,rsize=32768,wsize=8192,soft,udp,nolock,addr=192.168.2.6)

udp, async
6736
8126
192.168.2.6:/filme on /mnt/filme type nfs (rw,v3,rsize=32768,wsize=8192,soft,udp,nolock,addr=192.168.2.6)

tcp, sync
3121
6649
192.168.2.6:/filme on /mnt/filme type nfs (rw,sync,v3,rsize=32768,wsize=32768,soft,tcp,nolock,addr=192.168.2.6)

tcp, async
6649
6826
192.168.2.6:/filme on /mnt/filme type nfs (rw,v3,rsize=32768,wsize=32768,soft,tcp,nolock,addr=192.168.2.6)



Der Movieplayer ist nur am Puffern bei der hier dargestellten besten Einstellung "udp, async". Mit "tcp, async" gehts einwandfrei... ?!

Abgespielt wird ein TS-File mit AC3 und einer durchschnittlichen Rate von 4,3 Mbit/s (Spitzen = 7,6 Mbit/s).

Wieso ist da ein Unterschied? Macht der Movieplayer doch noch etwas anderes als das Script?

Capri
henry12
Einsteiger
Einsteiger
Beiträge: 145
Registriert: Sonntag 18. November 2001, 00:00

Beitrag von henry12 »

ich hatte mal einen Allnet 8fach Switch, der war für das Streamen nicht zu gebrauchen, nach Austausch läuft alles einwandfrei.
Ausserdem kann udp von einem Rechner mit 100MBit Fullduplex auf die DBoxmit 10MBit Halbduplex nicht richtig funktionieren. Versuche entweder auf dem Rechner mal mit Halbduplex zu arbeiten, oder lasse einfach tcp in den Einstellungen
wolgade
Semiprofi
Semiprofi
Beiträge: 1313
Registriert: Donnerstag 2. Dezember 2004, 00:18

Beitrag von wolgade »

Du könntest mal versuchen, den Puffer des Movieplayer zu vergrößern.

Das Essu-Skript zeigt dir die durchschnittliche Datenrate an. Es sagt dir nicht, ob es während der Messung eventuell Zeiträume gegeben hat, wo gar nichts ging.

Du könntest mal deine Netzwerkkarte auf Halbduplex umstellen und schauen, welche Ergebnisse das Essu-Skript liefert. Auf der ersten Seite dieses Threads findest du Ergebnisse meiner damaligen Testerei.

Bei mir hat sich damals am Ende dann doch der im Router integrierte Switch als Bremse herausgestellt. Den habe ich dann getauscht. Im Eisfair muß ich die Netzwerkkarte außerdem zwischen halbduplex und vollduplex umschalten, je nachdem ob ich aufnehmen oder wiedergeben will. Das aber auch erst, seit die 3Com-Karte ihren Dienst quittiert hat und wieder durch Realtek ersetzt wurde.

Was ich sagen will: Es gibt kein wirkliches Patentrezept. Die Performance hängt sehr von der eingesetzten Hardware und ihren Einstellungen ab. Es führt kein Weg daran vorbei, alle Permutationen durchzuprobieren. Dabei ist das Essu-Skript Gold wert.
wolgade
Semiprofi
Semiprofi
Beiträge: 1313
Registriert: Donnerstag 2. Dezember 2004, 00:18

Beitrag von wolgade »

henry12 hat geschrieben:Ausserdem kann udp von einem Rechner mit 100MBit Fullduplex auf die DBoxmit 10MBit Halbduplex nicht richtig funktionieren.
Das würde ich so pauschal nicht sagen, auch wenn es theoretisch so sein müßte. Ich hab bei meiner damaligen Testerei mit verschiedener Hardware und verschiedenen Einstellungen sämtliche allgemeinen Ratschläge sowohl bestätigt als auch widerlegt bekommen. Es hängt halt davon ab, wie Netzwerkarte und Switch mit den Kollisionen umgehen.
capri
Interessierter
Interessierter
Beiträge: 53
Registriert: Dienstag 4. Juni 2002, 12:26

Beitrag von capri »

Hallo und danke für die schnellen Antworten!

Das es kein Patentrezept gibt und man viel probieren muß ist mir klar - irgendwie wollen wir das ja alle auch ;-) Aber das essu Scirpt hilft einem dabei leider nur bedingt weiter - bei mir hat es z.B. gute Performance unter UDP angezeigt. Starte ich den Movieplayer kommt dabei eine ganz schlechte Übertragunsrate raus (ohne Wabberqueue sofortiges andauerndes zittern; mit Wabberqueue nach ca. 10-15 sek. Puffern...).

Direkt danach das Essu Script oder einfach den Befehl "if=... of=..." ergibt wieder ein schnelles Ergebnis.


PS: Server ist 10halbduplex...
wolgade
Semiprofi
Semiprofi
Beiträge: 1313
Registriert: Donnerstag 2. Dezember 2004, 00:18

Beitrag von wolgade »

Dann guck doch mal, was bei Vollduplex passiert! Außerdem könntest du noch versuchen, testweise mal einen der beiden Switches rauszunehmen, auch wenn es keinen Spaß, ein langes Kabel quer durch die Bude zu ziehen.

Frau oder Freundin vorher unbedingt ins Kino schicken! :D
Arbitrated_Loop
Interessierter
Interessierter
Beiträge: 24
Registriert: Sonntag 24. Oktober 2004, 19:43

Beitrag von Arbitrated_Loop »

Ich bin nicht sicher, ob es hier schon mal geschrieben wurde, aber ich habe die Erfahrung gemacht, dass das Streamen deutlich stabiler ist und es so gut wie nie zum Abbruch kommt, wenn die Box per Switch mit dem Rechner verbunden ist statt einem Cross-Kabel.

Von der Logik her, hätte ich es eher andersherum vermutet, aber nachdem ich permanent Probleme hatte, habe ich irgendeinen Billig-Switch dazwischen gehängt und siehe da, ohne irgendeine Änderung an der Konfiguration, hatte ich keine Probelem mehr.

Möglicherweise übernimmt der Switch die evtl. sonst fehlende Pufferleistung. Vielleicht sozusagen das Zünglein an der Waage.


Gruss
AL
wolgade
Semiprofi
Semiprofi
Beiträge: 1313
Registriert: Donnerstag 2. Dezember 2004, 00:18

Beitrag von wolgade »

Arbitrated_Loop hat geschrieben:Ich bin nicht sicher, ob es hier schon mal geschrieben wurde, aber ich habe die Erfahrung gemacht, dass das Streamen deutlich stabiler ist und es so gut wie nie zum Abbruch kommt, wenn die Box per Switch mit dem Rechner verbunden ist statt einem Cross-Kabel.
Hängt sehr vom Switch ab. Der Switch meines alten DSL-Routers war ein Bremsklotz. Cross-Kabel war da teilweise besser. Nachdem ich meinem Eisfair und der D-Box einen eigenen (anderen) Switch spendiert hatte, lief es um Längen besser als mit Cross-Kabel. Auf den ersten Seiten dieses Threads gibt es meterlange Tabellen meiner damaligen Meßorgie.

In einem anderen Thread (http://tuxbox-forum.dreambox-fan.de/for ... hp?t=34783) habe ich noch mal wie wild gemessen. Ergebnis war, daß ein fest in den Kernel einkompilierter NFS-Server performanter war, als ein NFS-Server als Kernelmodul, jedenfalls bei schwachbrüstiger Serverhardware. Dieser Punkt ist für die NAS-Fraktion vielleicht ganz interessant.
Von der Logik her, hätte ich es eher andersherum vermutet,
Ich habe im Zuge meiner Netzwerkoptimiererei festgestellt, daß man mit Logik nicht sehr weit kommt. Dazu müßte man wirklich detailiert wissen, was auf den einzelnen Netzwerkschichten passiert bzw. schiefgeht, inklusive Timing, Kollisionsbehandlung und Flußsteuerung der beteiligten Netzwerkkomponenten.