NFS-Server SFU3.5

[chicane_200676]

Nee, soweit ich mich erinnern kann, mußte ich dann doch noch das 'rw' selber eintragen, aber alles andere war dann ok.

CU,
Chicane


Frage: Wenn die Aufnahme läuft und ich im Windows-Explorer auffrischen klicke, um zu sehen, ob die Filegröße wächst, updatet er nicht bis die Aufnahme beendet ist. Ist das bei euch auch so ?

[Darth Valium]

aloah,

als tip fuer alle, die evtll. probleme mit nem sauberen empfang haben:

wsize=n
Set the write buffer size to n bytes. The
default value is 32768 when using Version 3 of
the NFS protocol. The default can be negotiated
down if the server prefers a smaller transfer
size. When using Version 2, the default value is
8192."

wenn ihr also einen nfs3-server habt, testweise mal den wert auf 32kb erhoehen.

zudem hab ich noch in den hp-docs nen hinweis gefunden, dass der write-buffer der blockgroesse des zielmediums entsprechen sollte(wobei diese wohl bei klug formatierter movie-partition zu hochdosiert ist)

dann fuer alle, die sfu am laufen haben(oder einen anderen nfs3 server), sei empfohlen, das ganze so aussehen zu lassen:

rw, rsize=32768 ,wsize=32768 ,nfsvers=3

wobei es sein kann, dass es "v3" statt "nfsvers=3" (alternativ "vers=3") heissen sollte. bei grossen wsize&rsize werten ist natuerlich tcp zu waehlen, da ansonsten bei einem loss wieder alle paekchen erneut gesendet werden muessen(standard dbox2 mtu=1500; bedeutet bei einem packet loss bei udp bei block size 8kb resend von 6 frames), bei tcp eben nur das verlorene.(alternativ: wsize&rsize 1024, proto udp;btw: bei tcp transport sollte bei nfs der server die blocksize bestimmen).

dann gibts (fuer ...ix) noch die "async" option beim export einer nfs-share, die bewirkt, dass der nfs-server nicht erst den schreibvorgang beendet, bis der das naechste datenpaket annimmt (leider habe ich aehnliches bei keinem nfs-server fuer win gesehen).

noch ein paar tips bzgl timeo und wsize:

timeout > 5%, ~ badxid
Server zu langsam, timeo größer machen

timeout > 5%, badxid ~ 0
Pakete gehen verloren, rsize wsize kleiner machen

aus der manpage von netBSD:

Increasing the read and write size with the -r and -w
options respectively will increase throughput if the
hardware can handle the larger packet sizes. The default
size for version 2 is 8k when using UDP, 64k when using
TCP. The default size for v3 is platform dependent: on
i386, the default is 32k, for other platforms it is 8k.
Values over 32k are only supported for TCP, where 64k is
the maximum. Any value over 32k is unlikely to get you
more performance, unless you have a very fast network.

wers gaz hartnaeckig treiben will, halte sich an die test routinen aus dem nfs-faq:

You will want to experiment and find an rsize and wsize that works and is as fast as possible. You can test the speed of your options with some simple commands, if your network environment is not heavily used. Note that your results may vary widely unless you resort to using more complex benchmarks, such as Bonnie, Bonnie++, or IOzone.

The first of these commands transfers 16384 blocks of 16k each from the special file /dev/zero (which if you read it just spits out zeros really fast) to the mounted partition. We will time it to see how long it takes. So, from the client machine, type:

# time dd if=/dev/zero of=/mnt/home/testfile bs=16k count=16384

This creates a 256Mb file of zeroed bytes. In general, you should create a file that's at least twice as large as the system RAM on the server, but make sure you have enough disk space! Then read back the file into the great black hole on the client machine (/dev/null) by typing the following:

# time dd if=/mnt/home/testfile of=/dev/null bs=16k

Repeat this a few times and average how long it takes. Be sure to unmount and remount the filesystem each time (both on the client and, if you are zealous, locally on the server as well), which should clear out any caches.

Then unmount, and mount again with a larger and smaller block size. They should be multiples of 1024, and not larger than the maximum block size allowed by your system. Note that NFS Version 2 is limited to a maximum of 8K, regardless of the maximum block size defined by NFSSVC_MAXBLKSIZE; Version 3 will support up to 64K, if permitted. The block size should be a power of two since most of the parameters that would constrain it (such as file system block sizes and network packet size) are also powers of two. However, some users have reported better successes with block sizes that are not powers of two but are still multiples of the file system block size and the network packet size.

Directly after mounting with a larger size, cd into the mounted file system and do things like ls, explore the filesystem a bit to make sure everything is as it should. If the rsize/wsize is too large the symptoms are very odd and not 100% obvious. A typical symptom is incomplete file lists when doing ls, and no error messages, or reading files failing mysteriously with no error messages. After establishing that the given rsize/ wsize works you can do the speed tests again. Different server platforms are likely to have different optimal sizes.

fuer die crosslinker unter euch sollte es dahingegen recht einfach sein; prot tcp, block size 64kb(maximum) netzwerk quali koennt ihr ja mal mit nem floodping und ner grossen packetsize testen(bsp: ping -f -s 1024 x.x.x.x), zudem koennt ihr dann auch halbwegs abschaetzen, wie ihr den timeout vom nfs setzen muesst.

viel spass beim tuefteln!

[petgun]

hi,
danke fuer die Tips!

cu,
peter

[MacLeod]

@ Darth Valium :
VERRY BIG THANKS!!!!!

ich glaube nun hab ich das auch zum laufen bekommen
habe nun vier aufnahmen ohne abbrüche hinbekommen.
meine einstellungen in den mount optionen nun:
rw,nfsvers=3
nolock,rsize=32768,wsize=32768
im sfu habe ich von den standardwerten nur von udp auf tcp gewechselt.
muß ich mir nun nur noch anschauen ob das mit der wiedergabe auch hinhaut. ich werde es weiter testen

nochmals fix bedankt!

cu
MacLeod

[Kaligula]

Hallo zusammen,

@MacLeod:
NFS über TCP macht keinen sinn. Du hast dann den gleichen Nachteil wie Stream über TCP. Jedes Paket muß bestätigt werden und dass ist eben bei 10Mbit halfduplex sehr eng.
NFS hat seine eigene Absicherung (ähnlich wie udrec), so daß Packete die Fehlerhaft ware nochmal angefordert werden. Dies hält den Stream in Richtung Box klein.

Soweit zum Prinzip.
Was ich natürlich nicht genau weiß ist, ob UDP in Deinem speziellen Fall gut funktioniert.

[MacLeod]

na ja, ok...
aber,

bei grossen wsize&rsize werten ist natuerlich tcp zu waehlen, da ansonsten bei einem loss wieder alle paekchen erneut gesendet werden muessen(standard dbox2 mtu=1500; bedeutet bei einem packet loss bei udp bei block size 8kb resend von 6 frames), bei tcp eben nur das verlorene

dann ist es hier wohl falsch beschrieben, oder ich hab das falsch interpretiert. jedenfalls lüppt tcp bei mir besser als udp. warum weiß ich nicht.

wenn ich streams die per udp aufgezeichnet worden sind, (ggrab,udrec-ts) mit dem movieplayer wiedergebe habe ich immer wieder stockende bilder und asyncronitäten....
demnach funzt wohl udp bei mir nicht richtig, oder wie soll ich das nun deuten? aber warum zum teufel nur, w a r u m ???


cu
MacLeod

[Darth Valium]

falsch interpretiert:

umso groesser der rahmen, desto mehr pakete muessen geschickt werden.
geht eines dieser pakete verloren bzw. kaputt, wird via tcp genau dieses paket nochmal gesendet, per udp hingegen der ganze frame nochmal.

letzeres ist bei einem stream bei schmaler bandbreite & wenig buffer schnell mal ein async, wenn nicht gar das ende des streams.

allerdings sollten in nem kleinen netz kaum udp paekchen verloren gehen(eigentlich gar keins). teste mal dein netz mit hardcore-pings auf aussetzer und durchlaufzeit(bzw. die verbindung dbox<->nfs-server).

[MacLeod]

ok, verstanden...

ämm, was meinst du mit hardcore-pings? ping"dbox-ip" /t ?
ich bin da nicht so der held was netzwerk angeht...
wie sieht der befehl denn von der dbox aus, per telnet auf die box und dann?
manoman is das peinlich

bin gerade dabei per udp zu streamen, die ersten versuche sahen doch vielversprechend aus, nun habe ich bei der box rw,nfsvers=3 und dann auf 8k gestellt, im sfu habe ich auch auf 8k gestellt. na mal sehen...


cu
MacLeod

[Darth Valium]

einfach ein telnet auf deine dbox, und von dort aus:

Code: Alles auswählen

ping -s 1024 IP_deines Aufnahmerechners

das kannste ruhig mal "laufen" lassen (2h), dann abbruch mit strg+c; erhaelst dann eine kleine zusammenfassung. fuer kniffelgie netzprobleme sicher nicht die beste loesung, aber gut um generell mal die leitungen zu testen.

eventuell macht es auch sinn am timeout zu basteln, wenn du zbsp merkst dass der ttl bis zum server zu "lange" ist.

btw, ich wuerde die aufnahme gerne im "lock" modus laufen lassen, damit mein windows xp keine chance hat, die aufnahme zu killen (f5(refresh) im aufnahmedir meiner dbox bricht immer meinen direktstream ab), hat das schon jemand hinbekommen?

[MacLeod]

supi !
hier mal das ergebnis der ping-statistic nach ca. 2std.:

6994 packets transmitted, 6994 packets recieved, 0% packet loss
round-tripp min/avg/max = 2.7/2.7/9.3 ms

sieht doch gut aus, oder?

eventuell macht es auch sinn am timeout zu basteln, wenn du zbsp merkst dass der ttl bis zum server zu "lange" ist.

ist das denn zu lange? wo kann ich denn den timeout verändern? und wie soll ich ihn verändern?
währe nett wenn du weiterhelfen könntest...
bin ja immer noch guter hoffnung, dass es irgendwann bei mir auch mal funzt

edit on:
schon ok... war mal wieder zu voreilig...
habe gerade die timeout von 0.8 auf 1s geändert, testaufnahme läuft im moment, bin mal gespannt.
edit off.

cu
MacLeod

[MacLeod]

hm...
nö, war leider wieder nix, so langsam bin ich am ende.
mit dem snap vom 22. ists nun auch so, wenn ne aufnahme abgebrochen wurde, ist sie zu ende, zuvor war es so, dass die aufnahme dann neu startete. ist das so gewollt?


MacLeod

[Darth Valium]

tjo, wenns dir hilft:

ich bin genau so sehr am verzweifeln wie du
bekomme auch keine einzige aufnahme via ds hin, bricht immer wieder ab wg. zu lahmer schreibleistung (auch wenn der udp stream vom durchsatz her (verwaltung->leistung) sehr vernuenftig aussieht, genauso wie die schreibleistung der hd. probiert habe ich jetzt sowohl omni als auch sfu.

ist halt wieder tes streaming angesagt. leider habe ich noch keinen dedizierten aufnahmeserver, der einzige rechner bei mir mit genug hd-space ist mein "richtiger", und es nervt gehoerig, waehrend einer aufnahme praktisch nix nebenher machen zu koennen. nfs waere da ne alternative gewesen, da es, vorausgesetzt es laeuft, sehr unempfindlich gg.ueber cpu- & hd-leistungs-fressenden tasks ist.

[petgun]

der einzige rechner bei mir mit genug hd-space ist mein "richtiger", und es nervt gehoerig, waehrend einer aufnahme praktisch nix nebenher machen zu koennen.

...JtG mit zB. udrec zwingt Dich zum daeumchendrehen waehrend einer Aufnahme ? Das darf nicht sein und sollte zuerst mal gefixt werden...welcher Task schluckt denn soviel CPU-Leistung waehrend einer Aufnahme ?

cu,
peter

[chicane_200676]

Hi,

also ich mache am Rechner, wenn die Box auf die NFS-Share schreibt, eigentlich auch nix mehr parallel, weil ich schon die Meldung bekommen hatte, "Datenstrom abgebrochen" oder so ähnlich. Allerdings lief dabei "versehentlich" ein Antivirus-Scanner im Hintergrund und die Platte war schon gut beschäftigt.

Was mich jedoch beim Lesen dieses Threads etwas wundert, ich habe auf der Box nix von NFS3 oder so eingetragen, das hat die Box beim ersten mouten selber gemacht. Da steht nur was in Richtung von "nolock,udp,rsize=8192,wsize=8192".
In der SFU habe ich dann noch irgendwo was von 8K eingestellt.

Das Streamen geht super, nur einen einzigen Abbruch bisher. Die Qualität ist auch sehr gut. Das größte Hindernis war nur die SFU.

Was mir noch aufgefallen ist - während des Streamens rödelt meine 160er 7200er Samsung volles Rohr rum. Bei streamen via JTG dagegen ist sie sehr ruhig unterwegs.... kann aber Zufall sein.

Vielleicht ist manchmal weniger mehr ? Und das NFS-streamen geht bei mir schon ab dem 01.05. ohne Probleme (Philips-Box).

Naja, nur so ein paar Gedanken...

Gruß,
Chicane

[MacLeod]

hm...
is ja alles sehr spannend....
bei dem einen gehts, beim anderen nicht. sehr komisch.
tja das sind nun meine nächsten tests, udrec ts klappt wunderbar, ohne resends ohne packet loss, tadellos. so weit so gut, nun aber wieder mein problem. wiedergabe über nfs-share, ruckelig und aussetzer... ich dreh durch
das einzige was zufriedenstellend wiedergegeben wird sind aufnahmen mit wingrab über vcl und movieplayer... das kann doch alles nicht sein.

MacLeod