Netzwerkgeschwindigkeit unter NFS/CIFS

Das Original Benutzerinterface Neutrino-SD incl. zapit, sectionsd, yWeb etc...
tha_haze
Einsteiger
Einsteiger
Beiträge: 249
Registriert: Samstag 8. Mai 2004, 20:14

Beitrag von tha_haze »

Tattergreis hat geschrieben:time dd if=/mnt/filme/Aufnahme/testfile_1gb_nfs of=/dev/null bs=8k
komisch, wollte jetzt auch einmal auf diese weise testen, aber meine box kennt anscheinend keinen time-befehl??
thegoodguy
Erleuchteter
Erleuchteter
Beiträge: 465
Registriert: Mittwoch 14. August 2002, 20:45

Beitrag von thegoodguy »

Sowohl dd als auch time muessen in der busybox eingbaut sein.
Standardmaessig sind sie es nicht bzw. dd nur in den normalen (nicht flash) rules.

Code: Alles auswählen

grep -r CONFIG_DD cdk/Patches/
cdk/Patches/busybox-flash.config:# CONFIG_DD is not set
cdk/Patches/busybox.config:CONFIG_DD=y
grep -r CONFIG_TIME cdk/Patches/
cdk/Patches/busybox-flash.config:# CONFIG_TIME is not set
cdk/Patches/busybox.config:# CONFIG_TIME is not set
zexma
Tuxboxer
Tuxboxer
Beiträge: 2067
Registriert: Mittwoch 6. März 2002, 15:29

Beitrag von zexma »

Tattergreis hat geschrieben:@ Doc FunRock

Setz Dich erstmal mit der Thematik etwas auseinander, bevor du hier rumnölst. Ob Du nun vom Device /dev/zero, /dev/hda1 oder /dev/wasweissich liest spielt überhaupt keine Rolle, solange das auszulesende Device in der Lage ist, die Daten schnell genug zu liefern, um die eigentliche Messung, um die es hier geht, nämlich der Durchsatz des Netzwerkes auf einen NFS-Share, nicht zu verfälschen. Daran ändert auch Deine Ignoranz gegenüber anerkannten und weit verbreiteten Methoden nichts. :roll:
Gruß, Tattergreis
ICh bin mir da auch nicht so sicher worauf Doc FunRock hinaus möchte.
Vielleicht sollte man sich aber hier aber mal klar machen was NFS / FTP "ist". Nützlich ist wie immer das OSI- bzw. das TCP/IP-Model.

Sowohl FTP als auch NFS sind in der obersten Layer (Application) des TCP/IP-Models angesiedelt. FTP ist ein "File Transfer Protokoll". Es ist ein verbindungsorientierter Dienst der Dateien (binär oder ASCII) angeschlossener systeme (bidirektional) per TCP(!) überträgt.

NFS ist hingegen ein "Network File System". Diese File Protokoll Suite ermöglicht einen Remote Zugriff auf Daten. NFS kommuniziert per "Mittelsmann" (RPC - Remote Procedure Call) zwischen client/server; zum Einsatz kommen hier TCP(!) oder UDP(!)

Ich sehe hier allerdings keinen Widerspruch, warum mit obigen Tests nicht die nutzbare Bandbreite ermittelt werden sollte.
Doc FunRock hat geschrieben:du muesstest von der box aus ein grosses file auf den server schaufeln - per NFS (nicht per ftp oder sonstwas). ferner muesstest du auf der box den transfer messen. kannst du das? nee, kannst du nicht, weil,auf der box der speicherplaz halt nicht vorhanden ist.
Ich glaube nicht das Doc FunRock der eigentliche Zweck/Vorgang klar ist. Denn "per FTP" bzw "per NFS" wird hier eh nichts "übertragen". Wenn man es denn so ausdrücken möchte, dann findet die eigentliche Übertragung per UDP/TCP statt. Und dies ist imho der "kasus knaktus". :roll:
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

Hi,
noch mal die ergaenzte Tabelle. Die Werte [MBit/sec] mit 2 Nachkommastellen sind mit der Tattergreismethode gemessen...bei mir mit der Stoppuhr da 'time' nicht funktioniert. Fuer meine Werte lege ich die Hand ins Feuer und @DocFunrock: meine Werte sind auf +- 0,01 MBit/sec genau, reproduzierbar und richtig umgerechnet ;-)

Code: Alles auswählen

   Name     |R-CIFS|W-CIFS|R-NFS |W-NFS |    Bemerkungen
-------------------------------------------------------------------------------
petgun      |6,00  |8,4   |8,32  |9,00  |rsize=32k,100mbit,Switch, Windows XP, SFU
Tattergreis | -    | -    |7,37  |7,12  |100mbit,Switch, Linux FLI4L
sky         |5,9   |8,1   | -    | -    |100mbit, Switch, W2K
MOhlmann    |5,9   |8,3   | -    | -    |NIC_PC:???, X-cable, XP
Treito      | -    | -    |9,2   |9,3   |100mbit, Switch, Suse 9.1
tHec        | -    | -    |8,3   |9,2   |rsize=32k,100mbit, Switch, W2k, SFU
@Tattergreis
Was sagst Du zu den Werten ? Da muss doch noch was zu optimieren sein bei Deinem System...kannst Du bitte noch genauere Angaben machen NIC/Switch/Linux XYZ. Ich kann nicht ganz nachvollziehen dass Du bei den Werten nicht mit Aufnahmeunterbrechungen bei TS-Direkaufnahme und mit einer ruckelnden Movieplayerwiedergabe zu kaempfen hast..???

cu,
peter

<edit>
Werte ergaenzt
<edit>
Zuletzt geändert von petgun am Donnerstag 22. Juli 2004, 08:11, insgesamt 1-mal geändert.
HEAD
Einsteiger
Einsteiger
Beiträge: 313
Registriert: Freitag 14. Februar 2003, 15:59

Beitrag von HEAD »

Schreib test:
real 19m 45.04s
user 0m 3.66s
sys 2m 59.79s
Ich denke das test von dev/null auf null würde das richtige durchsatz geben.
Bei aufzeichnung hab ich null probs.(aha linux nfs)
Tattergreis
Interessierter
Interessierter
Beiträge: 66
Registriert: Sonntag 19. Oktober 2003, 11:10

Beitrag von Tattergreis »

petgun hat geschrieben:...
@Tattergreis
Was sagst Du zu den Werten ? Da muss doch noch was zu optimieren sein bei Deinem System...kannst Du bitte noch genauere Angaben machen NIC/Switch/Linux XYZ. Ich kann nicht ganz nachvollziehen dass Du bei den Werten nicht mit Aufnahmeunterbrechungen bei TS-Direkaufnahme und mit einer ruckelnden Movieplayerwiedergabe zu kaempfen hast..???

cu,
peter
Never touch a running system :wink: Also bei mir funktioniert es wirklich einwandfrei. Deshalb hab ich mich auch noch nie an eine Optimierung gesetzt. Vielleicht ist auch gar nicht der mittlere Durchsatz entscheidend, sondern evtl. Einbrüche auf Seiten des NFS-Servers, die ab und zu mal auftreten können. Denn dann reißt der Datenstrom ab. Ich werde mich morgen aber mal ransetzen und mit verschiedenen Blockgrößen experimentieren.

Zu meiner Konfiguration:
  • NIC im Server: 100 MBit Intel 82558
    OS: Linux auf FLI4L-Basis, Kernel 2.4.26
    2 x Switch 100 MBit dazwischen (ging leider nur über 2 Switches, nur 1 Ethernet-Anschluß im Wohnzimmer und eine XBOX musste auch versorgt werden)
Gruß, Tattergreis
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

hi,
Tattergreis hat geschrieben: Never touch a running system :wink: Also bei mir funktioniert es wirklich einwandfrei. Deshalb hab ich mich auch noch nie an eine Optimierung gesetzt. Vielleicht ist auch gar nicht der mittlere Durchsatz entscheidend, sondern evtl. Einbrüche auf Seiten des NFS-Servers, die ab und zu mal auftreten können.
...bei dem Test mit 1GB auf NFS ist das eine Linie auf dem Netzwerkmonitor und Einbrueche waeren mir aufgefallen....aber jetzt wo Du es sagst: Mit NFS hatte ich bisher auch noch nie einen Abbruch (aber bei 9mbit/sec auch kein Wunder) und die reproduzierbare Streamabbrueche bei ca 7mbit/sec beziehen sich auf CIFS (laengeres Schreiben mit hoechster Datenrate nicht moeglich)....ich habe aber mal durch extremes verkleinern der Ethernet MTU-Sizedie Schreibrate unter NFS gezielt verringert und dann genau die gleichen Abbrueche.
Ich werde mich morgen aber mal ransetzen und mit verschiedenen Blockgrößen experimentieren.
bitte lass es uns wissen ob da was bei rauskommt....vielleicht faellt Dir ja auch noch was zu CIFS ein ;-) Unter http://www.psc.edu/networking/perf_tune.html#HighPerf gibt's Netzwerk-Tuningtips hauptsachelich fuer Linux aber auch fuer Windows.

viel Erfolg,
peter
tha_haze
Einsteiger
Einsteiger
Beiträge: 249
Registriert: Samstag 8. Mai 2004, 20:14

Beitrag von tha_haze »

Meine Testwerte sind auch nicht wirklich optimal:

- NFS Read: 8,0 MBit
- NFS Write: 7,6 MBit

Beide Werte sind Maximalwerte, da diese immer ein wenig schwanken.

Getestet mit:
- Eisfair Linux auf PII/300
- 100Mbit Karte
- 10/100 Mbit Switch (Netgear) <-- hier vermute ich das Problem
- IPtraf

Gefunden hab ich auch noch von IBM ein Performance Management Guide für NFS-Client und Server, vielleicht hilfts ja weiter, auf jeden Fall stehen einige interessante Sachen drin.

mfg haze
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

Code: Alles auswählen

   Name     |R-CIFS|W-CIFS|R-NFS |W-NFS |    Bemerkungen
-------------------------------------------------------------------------------
petgun      |6,00  |8,4   |8,32  |9,00  |rsize=32k,100mbit,Switch, Windows XP, SFU
Tattergreis | -    | -    |7,37  |7,12  |100mbit,Switch, Linux FLI4L
sky         |5,9   |8,1   | -    | -    |100mbit, Switch, W2K
MOhlmann    |5,9   |8,3   | -    | -    |NIC_PC:???, X-cable, XP
Treito      | -    | -    |9,2   |9,3   |100mbit, Switch, Suse 9.1
tHec        | -    | -    |8,3   |9,2   |rsize=32k,100mbit, Switch, W2k, SFU
tha_haze    | -    | -    |8,0   |7,6   |100mbit,Switch, Linux Eisfair
Hast Du NFS v3 ? Dann solltest Du 32k fuer rsize mal testen ob sich damit die Lesegeschwindigkeit erhoeht....auch wenn Du kein Gigabit Netzwerk hast...
Read and write size adjustments
Some of the most useful NFS tuning options are the rsize and wsize options, which define the maximum sizes of each RPC packet for read and write, respectively. The following reasons outline why you might want to change the read and write size values:

The server might not be capable of handling the data volume and speeds inherent in transferring the read/write packets, which are 8 KB for NFS Version 2 and 32 KB for NFS Version 3. This might be the case if a NFS client is using a PC as an NFS server. The PC may have limited memory available for buffering large packets.
If a read/write size value is decreased, there may be a subsequent reduction in the number of IP fragments generated by the call. If you are dealing with a faulty network, the chances of a call and reply pair completing with a two-packet exchange are greater than if there must be seven packets successfully exchanged. Likewise, if you are sending NFS packets across multiple networks with different performance characteristics, the packet fragments may not all arrive before the timeout value for IP fragments.
Reducing the rsize and wsize values might improve the NFS performance in a congested network by sending shorter packets for each NFS-read reply and write request. But, a side effect of this is that more packets are needed to send data across the network, increasing total network traffic, as well as CPU utilization on both the server and client.

If your NFS file system is mounted across a high-speed network, such as Gigabit Ethernet, larger read and write packet sizes might enhance NFS file system performance. With NFS Version 3, you can set the rsize and wsize values as high as 65536 when the network transport is TCP. The default value is 32768. With NFS Version 2, the maximum values for the rsize and wsize options is 8192, which is also the default.
cu,
peter
Zuletzt geändert von petgun am Donnerstag 22. Juli 2004, 13:14, insgesamt 1-mal geändert.
tha_haze
Einsteiger
Einsteiger
Beiträge: 249
Registriert: Samstag 8. Mai 2004, 20:14

Beitrag von tha_haze »

ja hab ich aber ich kann den rsize wert nicht erhöhen.
wenn ich nach dem mount-befehl mit 32k wieder mount aufrufe - siehe da - steht wieder rsize=8192 da

befehl:
mount -t nfs -o soft,udp,rsize=32768,wsize=8192,nolock 192.168.0.100:/dbox /mnt

resultat:
192.168.0.100:/dbox on /mnt type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.0.100)

egal ob ich auf der box oder per telnet mounte
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

hi,
ich habe bisher immer mit der Box gemeountet und bei den Mountoptionen auch den rsize Wert geaendert...das muss funktioniert haben da der Lesedurchsatz um 1Mbit gestiegen ist...mit telnet habe ich das bisher allerdings noch nicht ueberprueft.

cu,
peter
tha_haze
Einsteiger
Einsteiger
Beiträge: 249
Registriert: Samstag 8. Mai 2004, 20:14

Beitrag von tha_haze »

wenn ich statt 32k jetzt aber rsize=4k angebe bei den mount-optionen, dann scheint das auch zu funktionieren, zumindest steht es so dann beim nächsten aufruf von mount drin.

d.h. -> bei mir funktionieren keine werte über 8k (was auf nfsv2 deuten würde)
Tattergreis
Interessierter
Interessierter
Beiträge: 66
Registriert: Sonntag 19. Oktober 2003, 11:10

Beitrag von Tattergreis »

tha_haze hat geschrieben:wenn ich statt 32k jetzt aber rsize=4k angebe bei den mount-optionen, dann scheint das auch zu funktionieren, zumindest steht es so dann beim nächsten aufruf von mount drin.

d.h. -> bei mir funktionieren keine werte über 8k (was auf nfsv2 deuten würde)
Standardmäßig ist der Wert "NFSSVC_MAXBLKSIZE" auf "8*1024" festgelegt. Um eine größere Blocksize des NFS-Servers möglich zu machen, mußt Du ein neues Kernelmodul nfsd.o kompilieren, was Du vorher so gepatcht hast, das der Wert auf "32*1024" erhöht wird. Du benutzt Eisfair, wie ich gelesen habe. Arbeitest Du dort mit Kernel 2.4.26? Du kannst Dir gerne mein Modul hier 2.4.26_nfsd.o.zip herunterladen. Hab es mir selber heute kompiliert, weil ich vor dem gleichen Problem stand. :wink: Test mit höherer Blocksize läuft momentan. Wie gesagt, standardmäßig ist bei max. 8k Schluß, höhere Werte sind ausschließlich durch Patchen zu erzielen, wobei niedrigere Werte natürlich immer möglich sind.

Gruß, Tattergreis
tha_haze
Einsteiger
Einsteiger
Beiträge: 249
Registriert: Samstag 8. Mai 2004, 20:14

Beitrag von tha_haze »

danke für den tipp, nur leider kann ich die datei nicht runterladen, da lycos den referrer überprüft, und direkte links auf dateien nicht zulässt. dazu müsste ich erst über die hauptseite einsteigen, welche leider nicht vorhanden ist.
sollte die datei weniger als 800kb haben, empfehle ich dir funpic.de als free-hoster. ansonsten schick ich dir meine mail-adresse per pn.

mfg haze
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

..Test mit höherer Blocksize läuft momentan...
da bin ich echt gespannt was dabei rauskommt...
Vielleicht kann auch noch einer von Euch ein Statement zu UDP abgeben...ich glaube es wird nur TCP verwendet trotz der von NFS akzeptierten 'udp'-Mountoption....CIFS meckert auf der Konsole '...unknown option..'...

cu,
peter
Tommy
Tuxboxer
Tuxboxer
Beiträge: 4332
Registriert: Dienstag 7. Mai 2002, 17:04

Beitrag von Tommy »

@Tattergreis:

kannst Du mal eine Kurzanleitung für die Änderung des Eisfair posten? würde deinen patch auch gern testen habe mir den Eisfair aber nur nach doku "zusammengeklickt" :oops:
tha_haze
Einsteiger
Einsteiger
Beiträge: 249
Registriert: Samstag 8. Mai 2004, 20:14

Beitrag von tha_haze »

Statement zu UDP:

Code: Alles auswählen

UDP (140 bytes) from 192.168.0.9:800 to 192.168.0.100:2049 on eth0
UDP (1500 bytes) from 192.168.0.100:2049 to 192.168.0.9:800 on eth0
Unter Linux funktioniert NFS über UDP (siehe obige Pakete als Beispiel).
tha_haze
Einsteiger
Einsteiger
Beiträge: 249
Registriert: Samstag 8. Mai 2004, 20:14

Beitrag von tha_haze »

Habe das File von Tattergreis auf meinen Space geuppt, für alle, die darauf nicht zugreifen können.

Download 2.4.26_nfsd.o.zip
tha_haze
Einsteiger
Einsteiger
Beiträge: 249
Registriert: Samstag 8. Mai 2004, 20:14

Beitrag von tha_haze »

Code: Alles auswählen

/lib/modules/2.4.26-1/kernel/fs/nfsd/nfsd.o: kernel-module version mismatch
/lib/modules/2.4.26-1/kernel/fs/nfsd/nfsd.o was compiled for kernel version 2.4.26
while this kernel is version 2.4.26-1.
passt leider nicht ganz zusammen mit eisfair
Tommy
Tuxboxer
Tuxboxer
Beiträge: 4332
Registriert: Dienstag 7. Mai 2002, 17:04

Beitrag von Tommy »

...recht ein normales einkopieren in /lib/modules/2.4.26-1/kernel/fs/nfsd/ ?
tha_haze
Einsteiger
Einsteiger
Beiträge: 249
Registriert: Samstag 8. Mai 2004, 20:14

Beitrag von tha_haze »

anscheinend ja, nur funktioniert das mit eisfair nicht, da es sich um verschiedene kernelversionen handelt. --> selbst machen :wink:

http://www.uwsg.iu.edu/hypermail/linux/ ... /1172.html

allerdings wirft tattergreis nochmal einen blick darauf :D
Tattergreis
Interessierter
Interessierter
Beiträge: 66
Registriert: Sonntag 19. Oktober 2003, 11:10

Beitrag von Tattergreis »

Hi zusammen!

Weiter geht es erstmal mit den Testwerten bei höherer Blocksize:

Schreiben eines Files von /dev/zero auf den NFS-Server mit 65536 x 16k-Blöcken = 1 GByte
time dd if=/dev/zero of=/mnt/filme/Aufnahme/testfile_1gb_nfs bs=16k count=65536
Dauer: 17 min. 07 sec.
Errechneter Durchsatz: 7,98 MBit/s

Lesen eines Files vom NFS-Server mit 65536 x 16k-Blöcken = 1 GByte nach /dev/null
time dd if=/mnt/filme/Aufnahme/testfile_1gb_nfs of=/dev/null bs=16k
Dauer: 18 min. 33sec.
Errechneter Durchsatz: 7,36 MBit/s


Schreiben eines Files von /dev/zero auf den NFS-Server mit 32768 x 32k-Blöcken = 1 GByte
time dd if=/dev/zero of=/mnt/filme/Aufnahme/testfile_1gb_nfs bs=32k count=32768
Dauer: 16 min. 27 sec.
Errechneter Durchsatz: 8,30 MBit/s

Lesen eines Files vom NFS-Server mit 32768 x 32k-Blöcken = 1 GByte nach /dev/null
time dd if=/mnt/filme/Aufnahme/testfile_1gb_nfs of=/dev/null bs=32k
Dauer: 19 min. 33sec.
Errechneter Durchsatz: 6,98 MBit/s

Da ist also doch noch - zumindest beim Schreiben - ein höherer Durchsatz mit höheren Blockgrößen zu erzielen. :-) Ich werde die Blockgröße also mal auf 32k lassen, falsch macht man damit sicher nichts. Lesend ist da allerdings nichts zu machen, ganz im Gegenteil.

Gruß, Tattergreis
Tommy
Tuxboxer
Tuxboxer
Beiträge: 4332
Registriert: Dienstag 7. Mai 2002, 17:04

Beitrag von Tommy »

IMO ist der nfsd in eisfair 1.0.0 oder ist das nur die Eisfair version (http://www.eisfair.org/pack-eis/?p=nfsserver)
tha_haze
Einsteiger
Einsteiger
Beiträge: 249
Registriert: Samstag 8. Mai 2004, 20:14

Beitrag von tha_haze »

das ist nur die eisfair-version. du brauchst eine nfsd.o passend zu deiner kernelversion (ich nehme mal an 2.4.26-1 Non-SMP, wie ich)
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

Tattergreis hat geschrieben:..Da ist also doch noch - zumindest beim Schreiben - ein höherer Durchsatz mit höheren Blockgrößen zu erzielen. :-) Ich werde die Blockgröße also mal auf 32k lassen, falsch macht man damit sicher nichts. Lesend ist da allerdings nichts zu machen, ganz im Gegenteil...
wirklich merkwuerdig...laut den tuningtips muessten demnach die Pakete bei Dir beim lesen fragmentiert werden...und ich ein muesste ein Gigabit Netzwerk haben ;-) ich teste aber heute abend mal mit 64K..mal sehen ob ich wirklich ein Gigabit Netzwerk habe 8)

Hier die geaenderte Tabelle:

Code: Alles auswählen

   Name     |R-CIFS|W-CIFS|R-NFS |W-NFS |    Bemerkungen
-------------------------------------------------------------------------------
petgun      |6,00  |8,4   |8,32  |9,00  |rsize=32k,100mbit,Switch, Windows XP, SFU
Tattergreis | -    | -    |7,37  |8,30  |wsize=32k,100mbit,Switch, Linux FLI4L
sky         |5,9   |8,1   | -    | -    |100mbit, Switch, W2K
MOhlmann    |5,9   |8,3   | -    | -    |NIC_PC:???, X-cable, XP
Treito      | -    | -    |9,2   |9,3   |100mbit, Switch, Suse 9.1
tHec        | -    | -    |8,3   |9,2   |rsize=32k,100mbit, Switch, W2k, SFU
tha_haze    | -    | -    |8,0   |7,6   |100mbit,Switch, Eisfair Linux


weiterhin viel Erfolg bei der Suche nach der Lese-Performance Bremse....und ich tippe mal auf Deine suboptimale Verkabelung...

Code: Alles auswählen

2 x Switch 100 MBit dazwischen (ging leider nur über 2 Switches, nur 1 Ethernet-Anschluß im Wohnzimmer und eine XBOX musste auch versorgt werden)
Hast Du mal die Switches vertauscht...koennte was bringen wenn's unterschiedliche Fabrikate sind: Ich hatte 'frueher' einen Netgear 4 Port Switch/Router der etwa 10% langsamer (bei FTP) war als der billige D-Link-Switch den ich jetzt habe.

cu,
peter