komisch, wollte jetzt auch einmal auf diese weise testen, aber meine box kennt anscheinend keinen time-befehl??Tattergreis hat geschrieben:time dd if=/mnt/filme/Aufnahme/testfile_1gb_nfs of=/dev/null bs=8k
Netzwerkgeschwindigkeit unter NFS/CIFS
-
- Einsteiger
- Beiträge: 249
- Registriert: Samstag 8. Mai 2004, 20:14
-
- Erleuchteter
- Beiträge: 465
- Registriert: Mittwoch 14. August 2002, 20:45
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.
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
-
- Tuxboxer
- Beiträge: 2067
- Registriert: Mittwoch 6. März 2002, 15:29
ICh bin mir da auch nicht so sicher worauf Doc FunRock hinaus möchte.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.
Gruß, Tattergreis
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.
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".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.
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
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 ;-)
@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>
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
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.
-
- Einsteiger
- Beiträge: 313
- Registriert: Freitag 14. Februar 2003, 15:59
-
- Interessierter
- Beiträge: 66
- Registriert: Sonntag 19. Oktober 2003, 11:10
Never touch a running system 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.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
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)
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
hi,
viel Erfolg,
peter
...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.Tattergreis hat geschrieben: Never touch a running system 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.
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.Ich werde mich morgen aber mal ransetzen und mit verschiedenen Blockgrößen experimentieren.
viel Erfolg,
peter
-
- Einsteiger
- Beiträge: 249
- Registriert: Samstag 8. Mai 2004, 20:14
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
- 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
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
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
cu,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.
peter
Zuletzt geändert von petgun am Donnerstag 22. Juli 2004, 13:14, insgesamt 1-mal geändert.
-
- Einsteiger
- Beiträge: 249
- Registriert: Samstag 8. Mai 2004, 20:14
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
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
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
-
- Einsteiger
- Beiträge: 249
- Registriert: Samstag 8. Mai 2004, 20:14
-
- Interessierter
- Beiträge: 66
- Registriert: Sonntag 19. Oktober 2003, 11:10
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. 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.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)
Gruß, Tattergreis
-
- Einsteiger
- Beiträge: 249
- Registriert: Samstag 8. Mai 2004, 20:14
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
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
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
da bin ich echt gespannt was dabei rauskommt.....Test mit höherer Blocksize läuft momentan...
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
-
- Tuxboxer
- Beiträge: 4332
- Registriert: Dienstag 7. Mai 2002, 17:04
-
- Einsteiger
- Beiträge: 249
- Registriert: Samstag 8. Mai 2004, 20:14
Statement zu UDP:
Unter Linux funktioniert NFS über UDP (siehe obige Pakete als Beispiel).
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
-
- Einsteiger
- Beiträge: 249
- Registriert: Samstag 8. Mai 2004, 20:14
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
Download 2.4.26_nfsd.o.zip
-
- Einsteiger
- Beiträge: 249
- Registriert: Samstag 8. Mai 2004, 20:14
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.
-
- Tuxboxer
- Beiträge: 4332
- Registriert: Dienstag 7. Mai 2002, 17:04
-
- Einsteiger
- Beiträge: 249
- Registriert: Samstag 8. Mai 2004, 20:14
anscheinend ja, nur funktioniert das mit eisfair nicht, da es sich um verschiedene kernelversionen handelt. --> selbst machen
http://www.uwsg.iu.edu/hypermail/linux/ ... /1172.html
allerdings wirft tattergreis nochmal einen blick darauf
http://www.uwsg.iu.edu/hypermail/linux/ ... /1172.html
allerdings wirft tattergreis nochmal einen blick darauf
-
- Interessierter
- Beiträge: 66
- Registriert: Sonntag 19. Oktober 2003, 11:10
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
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
-
- Tuxboxer
- Beiträge: 4332
- Registriert: Dienstag 7. Mai 2002, 17:04
IMO ist der nfsd in eisfair 1.0.0 oder ist das nur die Eisfair version (http://www.eisfair.org/pack-eis/?p=nfsserver)
-
- Einsteiger
- Beiträge: 249
- Registriert: Samstag 8. Mai 2004, 20:14
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
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 habeTattergreis 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...
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)
cu,
peter