NFS Server der Daten puffert?

[karlmueller]

Mir ist gerade folgender Gedanke gekommen:

 

Wenn man am PC mit einer digitalen TV-Tunerkarte etwas auf die Festplatte aufnimmt, dann muss der MPEG-Datenstrom auf die HDD geschrieben werden, genauso wie wenn man etwas von der D-Box 2 per Direktaufnahme und NFS auf den PC streamt. Nur dass im ersten Fall (bei der Tunerkarte) die Aufnaheme auch weiterläuft wenn die Festplatte mal einen Moment lang überlastet / langsamer ist, bei der D-Box 2 variante ist die Aufnahme aber hin sobald die Daten einmal "nicht schnell genug geschrieben werden konnten". Ich denke mal dass das Programm welches die Sendungen über die DVB-Karte aufnimmt einfach so "schlau" ist und die MPEG-Daten in den RAM Puffert wenn die Festplatte gerade mal einen Performance-Abfall hat und die Daten dann später auf die HDD schreibt, was der NFS-Server von Microsoft aus dem SFU-Paket nicht macht. Der scheint die Daten so wie sie von der Box kommen auf die HDD zu schreiben und wenn die HDD gerade mal nicht schnell genug ist, dann fordert der NFS-Server die D-Box 2 wahrscheinlich auf die Daten nochmal zu senden, worauf diese dann den "die Daten konnten nicht schnell genug geschrieben werden"-Fehler bringt und die Aufnahme abbricht.

 

Wäre es nicht möglich einen NFS-Server zu schreiben, der die Daten auch puffert um so diesen Problem aus dem Weg zu gehen, oder gibt es so eine Funktion in anderen NFS-Server schon?

 

Danke schonmal!

 

mfg

 

karlmueller

[Worschter]

Hi,

 

es gibt glaub für SFU nen Registry Eintrag mit dem Puffern, auf jeden Fall erinnere ich mich da na sowas ähnliches.

 

Aber mal meine Theorie zu dem ganzen, würde man nen Switch haben der da zwischenpuffert

und hätte man die Netzwerkarte am Rechner auf 100MBit stehen, dann könnte nach so nem Festplattenhänger

der Puffer des Switches schnell genug ausgelesen werden, daß der Datenstrom nicht abreißt.

 

Aber das brauch ich Dir ja ansich nicht mehr zu erzählen

[Gast Lack]

HKLM\System\CurrentControlSet\Services\NfsSvr\Parameters\UseWriteCache

sollte auf 1.

Dann wird der Cache der HD zum puffern verwendet, man merkt das sogar optisch und akkustisch, weil sich die Platte dann nur mehr in etwas größeren Zeitabständen in Bewegung setzt.

 

Ich habs zumindest noch nie geschafft die Aufnahme durch arbeiten am PC zu zerstören.

 

Eines solltest du auch bedenken, wenn das Netzwerk relativ schwach ist und schon am letzten Zacken arbeitet, dann kann jede kleine Störung einen Absturz verursachen, oder anders ausgedrückt bei stabilem Netzwerk macht die Performance der Platte wahrscheinlich keine Schwierigkeiten.

[karlmueller]

Hallo,

 

also erstmal vielen Dank für den Tipp mit dem Registry-Eintrag der den Cache aktiviert!

 

Und zu dem 100 Mbit/s mit nem richtigen Switch:

 

Das Problem ist ja nur, dass keiner so genau weis welche Switches korrekt mit der D-Box 2 und ner 100 Mbit/s Verbindung zum Server arbeiten und da 10-20 Switches zu kaufen und auszuprobieren ist mir dann doch zu teuer und zu aufwändig. Wäre sicher die beste Lösung, aber wenn man net gerade den 6er im Lotto hatte und einen kompatiblen Switch erwischt hat, ist es halt mit vertretbarem Aufwand fast nicht durchführbar.

 

@Lack

Bezieht sich die Aussage von dir dass du noch nie abbrüche hattest auf aktivierten oder deaktivierten Cache?

 

mfg

 

karlmueller

[Gast Lack]

@Lack

Bezieht sich die Aussage von dir dass du noch nie abbrüche hattest auf aktivierten oder deaktivierten Cache?

Der Cache verbessert etwas die Performance des Netzwerks auch wenn man nicht nebenbei am PC arbeitet.

Wenn man aber am PC arbeitet ist diese Verbesserung tatsächlich relativ hoch.

So haben dass meine unzähligen Tests mit dem Netzwerkgeschwindigkeitsskript ergeben.

Die Sache ist nämlich die, wenn man z.B. während des Streamens irgendeine Datei von einem Ordner in einen anderen kopiert und sich nebenbei die Netzauslastungskurven des Taskmanagers ansieht dann erkennt man dass die Kurven auf einmal stark ausgezackt sind, und diese Zacken sind mit Cache viel harmloser. Hat man ein schwaches Netzwerk dann kann es passieren dass diese Zacken zu hoch werden und dadurch einen totalen Absturz verursachen.

Allerdings Cache hin oder her, ich hab eine optimale Netzwerkkarte gefunden und das ist das einzige Mittel was bei mir wirklich Wunder bewirkt hat (ist mit und ohne Cache stabil).

[karlmueller]

Der Cache bringt nicht (genug) es gibt immer noch Aufnahmeabbrüche wenn das RAID zu voll ist.

 

Ist denn so ein zur D-Box 2 kompatibler Puffernder Switch wirklich die einzige Möglichkeit?

 

mfg

 

karlmueller

[Worschter]

Ist denn so ein zur D-Box 2 kompatibler Puffernder Switch wirklich die einzige Möglichkeit?

es ist eine Möglichkeit. Aber eine die sehr erfolgversprechend ist.

[karlmueller]

Also ich hab ne erfreuliche Nachricht:

 

Es ist scheinbar möglich die Anfälligkeit des Streamings auch mit "normalen" Switches erheblich zu reduzieren und zwar durch ändern der Mountoptionen.

 

Hab einfach wsize=8192 in wsize=99999 geändert und mit dieser Einstellung erfolgreich Batman Begins gestreamt, beim letzten Versuch (bei gleicher RAID-Füllmenge aber mit wsize auf 8192) wurde der Film in 5 Teile geteilt. Scheinbar senkt die Erhöhung der wsize die Anfälligkeit des Streamings erheblich.

 

Nun würde mich aber folgendes Interessieren:

 

Was ist wsize und rsize genau, die Größe des Lese- und Schreibcaches und wenn ja wird auf der Box oder am Server gecachet? Und kann die Erhöhung der wsize nur in Verbindung mit dem Setzen des UseWriteCache Eintrages am Server was bewirken oder ist das davon unabhängig?

 

Und würde eine Erhöhung des rsize eine ähnliche höhere Fehlertolleranz bei der Wiedergabe von Filmen bewirken wie eine Erhöhung des wsize bei der Aufnahme?

 

Wäre es sinnvoll diese Werte noch weiter zu erhöhen um eine höhere Ausfallsicherheit zu erhalten?

 

Danke schonmal!

 

mfg

 

karlmueller

 

@Worschter

Jetzt scheint meine Pfush-Methode mit mehreren 10 Mbit/s Controllern bald genau so gut zu sein, wie deine Lösung mit dem puffernden Switches, oder?

[Worschter]

rsize un wsize sind die Paketgrössen die gesendet werden.

je grösser die sind, desto weniger Overhead desto höhere Datenrate.

Zumindest in der Theorie. In der Praxis komts da leider zu häufigeren kollisionen beim Lesen, weil die Box halt kein Vollduplex kann.

 

Dein Wert von wsize=99999 bringt null komma garnichts , weil das nur ne Vorgabe für den Max-Wert ist.

Der eigentliche Wert wird zwischen den beiden Systemen ausgehandelt, da hast Du ansich nicht allzuviel Einfluss drauf.

 

Wie Du eigentlich gemountet hast kannst in Tellnet sehen. Gib da mal

mount

ein.

Ideaerweise sind die Mount Werte vielfache von 1024 ums genauer zu sagen vielfache des MTU Wertes.

 

Jetzt scheint meine Pfush-Methode mit mehreren 10 Mbit/s Controllern bald genau so gut zu sein, wie deine Lösung mit dem puffernden Switches, oder?

 

Das werden wir an der Anzahl der noch folgenden Problem Thread sehen

[karlmueller]

Aber wenn der Wert so garnichts bringt, warum klappen die Aufnahmen jetzt auf einmal dann ohne Abbrüche? An nen Zufall glaub ich ehrlich gesagt wenn, denn vorher gingen 3-4 Testaufnahmen schief und nach ändern des Wertes sofort ein Erfolg!

 

Ist ja egal, hauptsache jetzt geht es!

 

Werd bei Gelegenheit mal testen wie sich eine Erhöhung der rsize auswirkt und wie Störresisten das System jetzt ist.

 

Werd dann wieder hier berichten!

 

Und noch etwas, in welcher Einheit sind die Wert rsize und wsize eigentlich?

 

mfg

 

karlmueller

[Worschter]

Aber wenn der Wert so garnichts bringt, warum klappen die Aufnahmen jetzt auf einmal dann ohne Abbrüche? An nen Zufall glaub ich ehrlich gesagt wenn, denn vorher gingen 3-4 Testaufnahmen schief und nach ändern des Wertes sofort ein Erfolg!

 

Weil die Nachbarin ihre Tage hat und der Mond im dritten Haus vom Jupiter steht, aber nicht wegen den wsize=99999

Es sei denn Du hattest zuvor nen geringeren eingetragen als der in Deinem System mögliche Max-Wert.

schau in Telnet nach der Ausgabe von

mount

 

Wsize ist in Byte angegeben und sollte wie schon gesagt ein vielaches des MTU Wertes sein, damit nicht durch

aufsplitten der Daten dann zusätzliche Pakete erstellt werden.

Mit rsize und wsize wird festgelegt, nach wievielen maximal MTU grossen Paketen der Empfang bstätigt

wird.

bisher habe ich keine Werte gefunden grösser 32768.

[Gast Charles Darwin]

Aber wenn der Wert so garnichts bringt, warum klappen die Aufnahmen jetzt auf einmal dann ohne Abbrüche? An nen Zufall glaub ich ehrlich gesagt wenn, denn vorher gingen 3-4 Testaufnahmen schief und nach ändern des Wertes sofort ein Erfolg!

 

Weil die Nachbarin ihre Tage hat und der Mond im dritten Haus vom Jupiter steht, aber nicht wegen den wsize=99999

Es sei denn Du hattest zuvor nen geringeren eingetragen als der in Deinem System mögliche Max-Wert.

schau in Telnet nach der Ausgabe von

mount

 

Wsize ist in Byte angegeben und sollte wie schon gesagt ein vielaches des MTU Wertes sein, damit nicht durch

aufsplitten der Daten dann zusätzliche Pakete erstellt werden.

Mit rsize und wsize wird festgelegt, nach wievielen maximal MTU grossen Paketen der Empfang bstätigt

wird.

bisher habe ich keine Werte gefunden grösser 32768.

Bringen diese wsize, rsize - Einstellungen auch was bei FTPFS ...eher net, oder?

 

War nur so eine Frage

[Worschter]

@Charles Darwin

 

nein, die kanst da nicht einstellen.

[Worschter]

Also es soll ja nicht heissen, daß ich mich nicht irren kann und ich das nicht zugeben würd,

nech reiflicher Überlegung zieh ich erst mal die Aussage mit dem vielfachen des MTU Wertes zurück.

 

Ich hab da evtl. 2 Sachen gemischt die nicht unbedingt zusammengehören.

Es gibt nen Zusammenhang zwischen MTU und Paketgrösse, aber ich bin mir nicht mehr sicher ob das

auch hiermit zusammenhängt.

 

Muss mich nochmal schlau machen. Die Werte der rsize und wsize sind jedenfalls vielfache von 1024

und das passt numal nicht direkt zum MTU.

[Gast Lack]

Meine Weisheiten:

 

Der Cache hat nichts mit wsize und rsize zu tun.

Der Cache ist eine reine Herdwaresache und abhängig von der verwendeten Platte.

 

rsize und wsize sind die Grössen der Datenpakete (oder Blockgröße), welche NFS-Client und Server austauschen und diese Größe hängt vom Betriebssystem bzw. von der NFS-Version ab. NFS v3 schafft maximal 64kB und NFS v2 nur 8kB, allerdings ist der verwendete Linuxkernel auf 32768 Bytes (32kB) bei UDP und TCP beschränkt. XP ist leider auf 8192 Bytes im Falle von UDP und 32768 Bytes im Falle von TCP beschränkt.

 

Der MTU gibt die Paketgröße an. Datenpackete haben in einem Netzwerk unabhängig vom jeweiligen Protokoll (NFS, FTP,...) eine bestimmte Größe (sehr oft 1500kB, wobei IPv4 maximal 9000kB zulässt).

Da nun wsize bzw rsize meist größer als der MTU sind und auch kein Vielfaches davon sind, kommt es gezwungenermaßen zu einer IP-Paket-Fragmentierung welche die CPU des jeweiligen Rechners ein wenig belastet und den Netzwerkverkehr unzuverlässiger macht aber ansonsten bewirkt das keine Einbußen in der erreichbaren Übertragungsgeschwindigkeit.

 

Normalerweise sollte NFS mit UDP und 32768kB Blockgröße immer am schnellsten sein, allerdings kann es bei irgendwelchen Schwächen im Netzwerk passieren dass hin und wieder ein Fragment verloren geht, in diesem Fall hat UDP gegeüber TCP klare Nachteile da dann immer der gesamte Block neu angefordert wird, im Falle von TCP wird aber nur das verlorene Packet (Fragment) neu angefordert. Das ist auch der Grund warum NFS mit UDP und 32768kB Blockgröße nicht immer am schnellsten ist (ein Verlust eines Fragments ist sehr "teuer").

TCP hat weiters den Vorteil dass es besser mit Geschwindigkeitsunterschieden fertig wird (Flow Control). Großer Nateil ist aber dass TCP grundsätzlich einen höhern Overhead erzeugt.

bearbeitet 19. Januar 2006 von Lack

[karlmueller]

Also dafür dass der Wert 99999 bei mir mit UDP funktioniert hab ich vielleicht ne Erklärung, denn ich setzte ja Windows Server 2003 ein und das unterliegt evtl. diese Beschränkungen nicht.

 

Aber kann mir einer Erklären, warum eine Erhöhung der Paketgröße eine größere Fehlertolleranz bewirkt? Und würde eurer Meinung nach eine Erhöhung des rsize einen ähnlichen Vorteil für die Wiedergabe bringen?

 

mfg

 

karlmueller

[Gast Lack]

Windows Server 2003 ist auch auf 32768 beschränkt.

Nur weil keine Fehlermeldung kommt heißt das noch lange nicht dass 99999 angenommen wird, wenn man mehr als 32768 eingibt wird trotzdem mit 32768 gemountet.

99999 ist ein Ding der Unmöglichkeit, das wird von keinem OS der Welt unterstützt und ist abgesehen davon mit NFS sowieso nicht möglich!!!

 

Was du mit "Fehlertolleranz" meinst weiß ich jetzt nicht, es ist nur so dass wenn angenommen 2% der IP-Packete (1500kB) verloren gehen, sich eine sehr große NFS-Blockgröße negativ auswirkt weil nicht nur die 1500kB neu angefordert werden sondern der gesamte Block mit z.B. 32768kB (gilt für UDP). Demnach ergibt sich bei relativ fehleranfälligen Netzen irgendwo ein Optimum der Blockgröße welches dann nicht beim höchst möglichen Wert liegt.

 

Erhöhung der rsize hat ganz genauso wie die wsize eine positive und eine negative Seite.

 

Ich fahre mit rsize und wsize auf 32768 am besten.

[danisane]

hmmm,

 

habe die abbrüche nur wenn ich ard Aufnehme (Marienehof "Waf Faktor")

 

RTL2, VOX, RTL, ORF, N24 machen keine probleme, nur ARD auch Hessen geht (ct TV)

 

Ich habe die Abbrüche immer an ungefähr der gleichen Stelle der Aufnahme.

 

W2K SRV, SFU, 100mbit Switch, Cat6 verkabelung

Streamen von 2 Boxen Gleichzeitig ohne Prob möglich (schreiben/schreiben oder schreibe/lesen egal )

 

Liegt bei mir an der ARD, Datenrate.

 

Gabs da nicht was mit Ringpuffer oder so an der Box ?

 

DaniSane

bearbeitet 10. Februar 2006 von danisane

[Worschter]

@danisane

 

Wenn Dein Netzwerk so funktioniert wie Du sagst, dann kann der Ringbuffer wriklich Sinn machen.

In den Aufnahme-Einstellungen Direktaufnahme Einstellungen -> Anz. Ringbuffer

Aber stell ihn nich zu hoch, (langsam steigern) denn wenn´s denn doch nicht reicht, dann hängt sich

die Box unter Umständen auf.

 

Mit SFU kannst Du übrigens die Max. Dateigrösse auf 0000 (unbegrenzt) stellen, nicht daß das die Urache war.