stehen nach meinen Erfahrungen/Messungen besser auf 'aus'.Synchrones Schreiben (O_SYNC): ein
Synchrones Schreiben (datasync): ein
Streamabbruch, Ruckler bei Wiedergabe, Lösungsversuch
-
- Erleuchteter
- Beiträge: 797
- Registriert: Sonntag 19. Februar 2006, 01:17
-
- Einsteiger
- Beiträge: 101
- Registriert: Mittwoch 25. Oktober 2006, 14:36
-
- Einsteiger
- Beiträge: 110
- Registriert: Dienstag 4. Oktober 2005, 23:21
-
- Einsteiger
- Beiträge: 110
- Registriert: Dienstag 4. Oktober 2005, 23:21
-
- Interessierter
- Beiträge: 24
- Registriert: Sonntag 24. Oktober 2004, 19:43
-
- Interessierter
- Beiträge: 53
- Registriert: Dienstag 4. Juni 2002, 12:26
Ergbenis NFS Speedtest ist zum Movieplayer unterschiedlich
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
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
-
- Einsteiger
- Beiträge: 145
- Registriert: Sonntag 18. November 2001, 00:00
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
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
-
- Semiprofi
- Beiträge: 1313
- Registriert: Donnerstag 2. Dezember 2004, 00:18
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.
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.
-
- Semiprofi
- Beiträge: 1313
- Registriert: Donnerstag 2. Dezember 2004, 00:18
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.henry12 hat geschrieben:Ausserdem kann udp von einem Rechner mit 100MBit Fullduplex auf die DBoxmit 10MBit Halbduplex nicht richtig funktionieren.
-
- Interessierter
- Beiträge: 53
- Registriert: Dienstag 4. Juni 2002, 12:26
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...
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...
-
- Semiprofi
- Beiträge: 1313
- Registriert: Donnerstag 2. Dezember 2004, 00:18
-
- Interessierter
- Beiträge: 24
- Registriert: Sonntag 24. Oktober 2004, 19:43
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
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
-
- Semiprofi
- Beiträge: 1313
- Registriert: Donnerstag 2. Dezember 2004, 00:18
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.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.
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.
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.Von der Logik her, hätte ich es eher andersherum vermutet,