Hallöchen,

ich frickle derzeit ein bisschen an meinem neuen Server rum, der eben auch Dateien
bereit stellen soll. Auf dem Server läuft ein Ubuntu Server 8.10 als Client fungiert (u.a.)
natürlich mein Arch-Desktop.
Mir ist jetzt aufgefallen, dass die Übertragungsraten über NFS sehr ungleichmäßig, quasi
stoßweise sind.

Beide Peers besitzen GBit onboard NICs (Desktop: Realtek 8168, Server: Via Velocity),
der Switch zwischen ihnen ist jedoch nur ein 100Mbit/Switch. Das Problem tritt auch auf,
wenn ich nicht die Via Velocity, sondern die ebenfalls vorhandene Via Rhine NIC (100 MBit)
nehme.

Was ich beobachte ist, dass die Übertragungen immer wieder auf fast 40-50 MB/s (mitunter
sogar 230 MB/s) spiken, aber Dolphin dann meldet, die Übetragungsgeschwindigkeit würde
auf ein paar hundert kb/s sinken und zwischendurch sogar gänzlich aufhören.
Tatsache ist jedoch, dass die Übertragungs-LEDs am Switch permanent wie irre flackern und
ebenso die Festplatte des Servers arbeitet.

Eine interessante Beobachtung zeigt auch die CPU-Last während des Transfers:
Solange die Geschwindigkeit hochspiked, geht die Last auf dem Server auf 0% (naja, ein
paar Prozent sinds schon, aber die sind durch die diversen Hintergrunddienste erklärbar).
Wenn mir mein System meldet, die Übertragung wäre angehalten, steigt die Last auf ca. 20-30%,
was mir eher realistisch erscheint.

Meine Vermutung ist, dass die Daten zunächst nicht direkt übertragen werden, sondern erst
in irgendeinem Cache landen und dann gemächlich mit 100MBit/s abgesendet werden.
Lasse ich mir die durchschnittliche Geschwindigkeit über den Transfer anzeigen, komme ich
bei genügen großen Volumina (>1 GB) auch auf einen Mittelwert von ca. 10 MB/s, was man
in einem 100 mbits LAN ohne tolle NICs durchaus erwarten würde.

Prinzipiell wäre das ja jetzt kein Problem, aber leider kommen einige Anwendungen damit
nicht klar und blockieren einfach während der tatsächlichen Übertragung. Außerdem
fühlt sich die Übertragung nicht wirklich "rund" an.

Die diversen Logs auf Server und Client (dmesg, /var/log/{daemon.log, messages, error.log}) zeigen
nichts verdächtiges. Ich habe schon diverse rsize, wsize-Paare probiert, jedoch ohne Ergebnis.

Der Server läuft auf jfs, aber auch wenn ich die Datenpartition auf xfs ändere, zeigt sich das
Problem davon unbeeindruckt, weshalb ich von einem Clientseitigen Problem ausgehe.

Ein kurzer Test mit dem Ubuntu-PC meiner Mutter zeigte dort auch wesentlich "ruhigere" Transfers.
Zwischendurch gabs zwar einige Schwankungen, aber die lagen durchaus im Rahmen, zumal die
Kiste eh etwas langsam ist 😉

Sodele,
ich hoffe ihr könnt mir da ein wenig helfen 😉

Vrob
Ich habe auch per Samba von WinXP auf mein Archlinux ca. 2GB übertragen. Die Trafficanzeige in Arch hat aber auch deutliche Schwankungen (100 KB/s bis 5MB/s, häufig flatternd) und sogar zweisekündige "Aussetzter" gezeigt.

Ich bin auch auf eine Erklärung/Lösung gespannt.

Thomas
Vrob, dein beobachtetes Verhalten bzgl. der Peaks / "Aussetzer" ist richtig und "normal". Während
des Transfers einer großen Menge am Stück entstehen zu unterschiedlichen Zeiten unterschiedliche
Flaschenhälse am Client und am Server. Generell ist der Flaschenhals bei 100baseTx sicher das Netzwerk, jede andere Komponente (Ram-Durchsatz, HD-Durchsatz) ist i.d.R. schneller.
Beim Kopiervorgang am Client werden Daten zuerst in den IO-Cache befördert (Erscheinung: Durchsatz ist wesentlich höher als das Netzwerk es hergibt). Im Idealfall kann die Anwendung frühzeitig weiterarbeiten. Bei großen Dateien ist der "schnelle" Cache irgendwann voll, dann muß auf die Abarbeitung durch den Flaschenhals Netz-Transfer gewartet werden (Erscheinung: 0-Byte Transfer). Serverseitig ist es ähnlich, wobei beim Empfangen dort der Flaschenhals eigentlich immer das Netzwerk ist, die Daten werden aber vom Filesystem gecached weggeschrieben. Wenn am Server die HD-IO nun sowieso hoch ist kann es aber auch sein das der Netztransfer nicht mit optimaler Geschwindigkeit verarbeitet werden kann.
Durchschnittlich (das deckt sich ja mit deinen Erfahrung) "pendelt" sich die Rate aber auf das langsamste Medium ein - in einem 100baseTx ist das eben das Netzwerk. Dabei egal, ob die Übertragung nun synchron oder asynchron erfolgt (Stichwörter!)

Man kann das sehr gut mit top sehen: Für einen Fileserver ist die CPU-Leistung meist nicht wesentlich relevant, eher die Komponenten IO-Controller/HDs/Netzwerk. Wenn du Client/Server bei einem solchen Transfer am mit top beobachtest wirst du sehen, das die CPU-Last bei (us,sy und ni) wenig ist, was das idle aber "auffrisst" ist der hohe Wert bei Wait(wa). Die CPU würde/könnte also "weiterrechnen", muß aber auf Daten warten (entweder HD-IO oder Net-IO).

Bei NFS solltest du v.a. ein paar "Eckdaten" abklopfen:
a) Erfolgt die Verbindung über TCP oder UDP?
b) Zeigen sich im Netz hohe Fehlerraten (bei UDP ob Fragmentierungsfehler vorliegen)?
c) Einigen sich alle Komponenten(Netzkarten, Switches) auf einen gemeinsamen Nenner, bei dir im Idealfall 100baseTx-FD, also FullDuplex?

Zu a) Poste doch mal für einen NFS-Share vom Client und Server:
Client: cat /proc/mounts (Den Block für einen NFS-Mount)
Server: exportfs -v (für die gleiche Freigabe)

Zu b) Klopfe die Ausgaben von:
netstat -s und ifconfig sowohl am Server als auch am Client auf Errors, Drops, Failure oder Fragementierungsfehler ab. Evtl. mal posten/anhängen nach einigen "Problemtransfers"

Zu c) Kannst du an Server/Client mit dem Befehl:
mii-tool (Im Paket net-tools) feststellen, auch mal mit: mii-tool -v schauen/posten.

Man kann bei NFS etliches an Performance (je nach Einsatzzweck) einstellen, verbessern/verschlechtern. Ein bißchen Lese/Stöberstoff (ist ein bißchen veraltet, vieles berücksichtigt den 2.6er Kernel nicht, aber prinzipiell weiter gültig):
http://nfs.sourceforge.net/
http://nfs.sourceforge.net/nfs-howto/

@tomprogrammer: Zu Samba kann ich wenig sagen, manches von oben würde auch für dich relevant sein. evtl. mal in den Dokus auf www.samba.org schauen, es gibt (AFAIK auch in Deutsch) auch etliche OpenBooks zu Samba. IMHO is NFS halt generell wesentlich performanter, "freundlicher" als SMB/Cifs.
Ok, danke für deine ausführliche Schilderung.

Mich interessiert jetzt noch wie ich den Festplattendurchsatz bestimmen kann.
Die Platte werkelt jetzt schon über acht Jahre in meinem Rechner, weswegen ich keine allzuhohe Schreib/Leserate erwarte. Aber sie tut (immer noch) guten Dienst 😉
Der Befehl hdparm -Tt /dev/sdx zeigt mir ja nur die Leserate. Außerdem ist mir der Unterschied zwischen 'cached read' und 'buffered read' nicht wirklich klar.

Ich werde jetzt mal testen, welche Performanceunterschiede zwischen NFS und Samba herrschen. Für Datentransfers zwischen Linux nutzte ich ja NFS, aber beim Datenaustausch mit WinXP muss ich auf Samba zurückgreifen.
tomprogrammer schrieb Mich interessiert jetzt noch wie ich den Festplattendurchsatz bestimmen kann.

Der Befehl hdparm -Tt /dev/sdx zeigt mir ja nur die Leserate. Außerdem ist mir der Unterschied zwischen 'cached read' und 'buffered read' nicht wirklich klar.
Bei hdparm: der Wert bei -T ist gemessen mit Cache, also wie Kernel+FS+HD dir i.d.. Daten ausliefern.
Zum realen Messen eben nur der HD ist der Wert von -t relevant.

Andere Tools zum Messen:
dd (aufpasssen, manpage lesen!) oder bonnie++
Danke, bonnie++ gibt mir alle Informationen die mich interessieren. 🙂
Ok, hier sind die Daten:
GerBra schrieb Zu a) Poste doch mal für einen NFS-Share vom Client und Server:
Client: cat /proc/mounts (Den Block für einen NFS-Mount)
Server: exportfs -v (für die gleiche Freigabe)
Vom Client: 
epiasrv:/srv/data /mnt nfs rw,vers=3,rsize=262144,wsize=262144,namlen=255,soft,nointr,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.6.20,mountvers=3,mountproto=tcp,addr=192.168.6.20 0 0
Vom Server: 
/srv/data       192.168.6.0/24(rw,async,wdelay,no_root_squash,no_subtree_check)
GerBra schrieb Zu b) Klopfe die Ausgaben von:
netstat -s und ifconfig sowohl am Server als auch am Client auf Errors, Drops, Failure oder Fragementierungsfehler ab. Evtl. mal posten/anhängen nach einigen "Problemtransfers"
Beide Outputs sagen nichts von Fehlern o.ä.
GerBra schrieb Zu c) Kannst du an Server/Client mit dem Befehl:
mii-tool (Im Paket net-tools) feststellen, auch mal mit: mii-tool -v schauen/posten.
Die Ausgaben von Server und Client unterscheiden sich nur in der Vendorzeile,
daher hier mal die vom Client: 
eth0: negotiated 100baseTx-FD flow-control, link ok
  product info: vendor 00:07:32, model 17 rev 2
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
  link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
Also ich würde das so interpretieren: Alles OK! 😉

Nichtsdestotrotz finde ich dieses Verhalten ein wenig... irritierend, aber ich nehme an,
man kann dagegen nicht besonders viel tun, oder? Gerade auf dem Server möchte ich
Lastspitzen eigentlich vermeiden.

Grüße,
Vrob
Wie bekomme ich denn Informationen über die Fragmentierungsfehler von gesendeten Paketen? Irgendwie hat das doch mit ping funktioniert, vermute ich.
Hi Vrob,

soweit würde ich auch sagen alles ok, also keine Fehler o.ä. was ich sehe.
Vorteilhaft für Performance ist das TCP statt UDP genutzt wird (in "guten" Umgebungen das beste).
Auch würde nur bei UDP ein evtl. Fragementierungsproblem eine nennenswerte Rolle spielen.

Zwei Ansatzpunkte sehe ich doch:
a) du exportierst deine NFS-exports mit async. Das würde ich mal auf den (mittlerweile) Default-Wert
sync stellen, also async aus den exports raus. Nach meinen Test sorgt async zwar für einen etwas
besseren Durchsatz (bei mir getestet ca. 200-300kb/s), beim Transfer sehe ich aber deutlich größere
Schwankungen im durchschnittlichen Datendurchsatz.

b) größeren Cache bei den In/Output Queues der Netzwerk-Sockets
Mit: 
cat /proc/sys/net/core/rmem_default
cat /proc/sys/net/core/wmem_default
kannst du die momentanen Werte sehen. Bei 2.4er Kernel waren die 64k, beim 2.6 AFAIK 128k (oder
dynamisch bestimmt?).
Erhöhen dieser Caches am NFS-Server zeigt bei mir eine deutlich geringere Server-Last (weniger wait, mehr idle bei top). Ich habe sie aktuell auf 256k 
echo 262144 > /proc/sys/net/core/rmem_default
echo 262144 > /proc/sys/net/core/rmem_max
echo 262144 > /proc/sys/net/core/wmem_default
echo 262144 > /proc/sys/net/core/wmem_max
Eine weitere Möglichkeit (je nach dem wieviele Clients/User/NFS-Zugriffe in der Umgebung vorkommen) ist die Erhöhung der Anzahl der nfsd-Instanzen. Per defualt sind das momentan 8, ich starte hier 16.
Wird geregelt über /etc/conf.d/nfs -> NFSD_OPTS=
Weiterhin mounte ich an den Clients so, daß nur nfsv3 als Protokoll genutzt wird von den Client-Prozessen, ich habe keine Clients die damit nicht zurechtkommen.
MOUNTD_OPTS="--no-nfs-version 1 --no-nfs-version 2"
auch in der etc/conf.d/nfs

Dein Hauptproblem war/ist ja eher scheinbar das "Stocken" wenn bei der Übertragung der Übergang vom Schreiben in den Client-FS-Cache zum "realen" Kopieren übers Netzwerk passiert. Bzw. scheinbar
Durchsatzschwankungen gen Null während des Transfers.
Das allerdings sollte Clients (die ja zum Abschluß des Transfers auf die Rückmeldung von Daemons und Kernel warten sollten) nicht aus dem Tritt bringen. Gibt es Progs/Tools die dir da besonders Probleme machen? Ich sage mal: ein cp, ein dd oder die Kopieraktionen von mc oder thunar haben da keinerlei Probleme mit.

Ich finde eine gute Kombination zum Testen des Durchsatzes auch während der Verbindung ist:
eine große Datei (größer als der Gesamt-Ram) nehmen (oder erzeugen z.B. mit:
dd if=/dev/zero of=/tmp/bigfile bs=1m count=2000)
Solch eine Datei dann auf den NFS-Mount kopieren oder auch lesen: 
dd if=/tmp/bigfile bs=64k | pv > /mnt/data/bigfile
(/mnt/data halt nur einen eigenen Mountpoint ersetzen)
Man sieht durch pv (//Edit: pv ist ein Paket aus community) sehr gut:
a) den anfänglichen "Peek" wenn der Client-FS-Cache erstmal gefüllt wird
b) die "Stockung", wenn dieser Cache "voll" ist und erstmal durch das Ethernet "abgearbeitet" wird.
c) Die "Angleichung" des Transfers an den Durchsatz des Flaschenhalses (also Netzwerk bei 10/100MB). Während dieses Transfers schwankt die Durchsatzrate auch, das liegt aber dann IMHO an den Disk-IO-Dingen, auch ist die Schwankung gering (bei mir geht es z.B. nie unter 5Mb/s) und sollte sich im Sekunden/Millisekunden-Bereich bewegen. Der Hauptanteil sollte sich bei 100Mbit-FD um die 10-11 MB/s bewegen was auch die von dd gemeldete Durchschnitts-Transferrate sein sollte.

Bei allen Veränderungen an exports, /proc Werten usw. solltest du zwischen den Tests am Client die nfs-mounts aushängen und am Server den nfsd und portmap neu starten damit die Tests saubere
Ausgangsbedingungen haben.
tomprogrammer schrieb Wie bekomme ich denn Informationen über die Fragmentierungsfehler von gesendeten Paketen? Irgendwie hat das doch mit ping funktioniert, vermute ich.
netstat -s zeigt das i.d.R.
Fragmentierte Pakete sind auch nichts per se böses, lediglich bei UDP muß halt der komplette RPC-Transfer wiederholt werden bei Errors durch Fragmentierung (da verbindungsloser Transfer),
bei TCP langt es das betroffene Paket neu zu senden.

Nur generelle Fragmentierung ist schlecht, verringert den Datendurchsatz, wenn Pakete von den am Transfer beteiligten Devices in unterscheidliche Größen gepackt werden.
Ethernet-Default ist eine MTU von 1500. Wenn beim Transfer ein device jetzt eine kleinere MTU hat dann
entstehen dort Fragmente (die entweder so transportiert werden oder verworfen und neu angefordert werden). Jedesmal kostet dieser Vorgang Zeit oder verhindert eine erfolgreiche Datenübertragung sogar.

Ein bekanntes Problem ist das z.B. bei DSL (also PPP over Ethernet). Hier müssen TCP-Pakete inkl. Header in ein PPP-Paket "eingepackt" werden. Wenn beide Devices jetzt eine MTU von 1500 haben, dann
entstehen durch den PPP-Header bei großen Paketen automatsich Fragemente. So werden z.B.
manche Webseiten nicht angezeigt o.ä. Deshalb setzt man bei PPPoE die MTU für das Ethernet-Device meist auf 1492, so passt das wieder in die MTU von 1500 des ppp-Devices....

Ob man im LAN bzw. beim Transfer so ein Problem hat kann man wie gesagt mit netstat -s sehen, auch ifconfig sollte hohe Werte bei den Fehler-Modi bei RX/TX haben.
Oft langt aber schon ein:
tracepath zielrechner
Im Lan sollte pmtu immer bei 1500 liegen, eine mtu-Änderung (z.B. auf 1492) sollte lediglich auf Routern erfolgen.
Hallo GerBra,

erstmal danke, dass du so ausführliche Beiträge schreibst 🙂

Ich kann die von dir beschriebenen Schritte jetzt ziemlich gut nachvollziehen:

Top zeigt das ziemlich genau an: Während der "Stockphase" ist zunächst der idle beinahe 99%, anschließend geht der wait-Wert hoch. Sind die Daten dann angekommen, steigt moderat der sys-Wert und kcryptd (Festplatte ist verschlüsselt) rutscht nach oben. Dank Hardwarebeschleunigung ist das aber ein Klacks 😉

Ich habe auch die von dir vorgeschlagenen Tipps ausgeführt, aber leider mit mäßigem Erfolg.
Das Erhöhen des Caches hat knapp 1 MB/s erhöhte Geschwindigkeit gebracht, aber sonst
hat sich nicht viel geändert.
Die mountd Optionen waren bei mir schon als Standard eingetragen 😉

Leider gehen die wenigsten Programme bei mir so sorglos mit dem Stocken um:
mc ist direkt gecrashed nachdem der Cache das erste mal voll war,
pv scheint auch so seine Probleme damit zu haben: Die gesamte Anzeige (der Laufbalken, Zeit und Geschwindigkeit) stoppen ebenso und bewegen sich erst wieder, wenn Daten gecached werden,
dolphin bzw. KDE scheint während eines Kopiervorgangs zwar nicht zu blocken, aber ist subjektiv weniger responsiv.

In den wenigen Phasen, in denen die Ansicht aktualisiert wird (insbesondere bei Dolphin funktioniert das), geht die Rate auch auf ein paar kb/s runter, sie bleibt nicht durchweg über 5 MB/s wie bei dir.

Grüße,
Vrob
Vrob schrieb Leider gehen die wenigsten Programme bei mir so sorglos mit dem Stocken um:
mc ist direkt gecrashed nachdem der Cache das erste mal voll war,
pv scheint auch so seine Probleme damit zu haben: Die gesamte Anzeige (der Laufbalken, Zeit und Geschwindigkeit) stoppen ebenso und bewegen sich erst wieder, wenn Daten gecached werden,
dolphin bzw. KDE scheint während eines Kopiervorgangs zwar nicht zu blocken, aber ist subjektiv weniger responsiv.
In den wenigen Phasen, in denen die Ansicht aktualisiert wird (insbesondere bei Dolphin funktioniert das), geht die Rate auch auf ein paar kb/s runter, sie bleibt nicht durchweg über 5 MB/s wie bei dir.
Hm, evtl. doch noch ein Problem mit den NICs bzw. dem Switch....
Teste doch mal ein wenig die generelle Netzwerk-Performance, unabhängig von NFS. Installiere mal die
Tools iptraf und iperf. Weiterhin hänge ich mal das Tool netio an, hatte ich aus den im Netz verfügbaren Sourcen kompiliert(i686).

iptraf (als root laufen lassen) ist ein Traffic-Monitor (zu vielen Zwecken sehr hilfreich). Starte diesen mal am Client oder Server und gehe in die Option "Detailed interface statistics", dann eth0. Damit kannst
du links unten Input/Output-Durchsatz messen, was aktuell interessiert wäre Total rates. Bei den nachfogenden Tests dies mal im Auge behalten, ob dort während die Tests laufen Durchsatzeinbrüche nachvollziehbar wären.

Die Tests:
a) iperf
Am Server: iperf -s
Am Client: 
iperf -t30 -c dein_server
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-30.0 sec    338 MBytes  94.6 Mbits/sec
(Im iptraf fenster sollte total rate beim Transfer immer zwischen 11000-12000 kb/s liegen)

iperf -t30 -c dein_server -d
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-30.0 sec    318 MBytes  88.9 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-30.1 sec    304 MBytes  84.5 Mbits/sec
(Transfer in beide Richtungen, bei iptraf sollte total rate zw. 20000-21000 kb/s liegen, also volle FullDuplex Sättigung)
b) netio
Netio testest per Default Transfers mit unterschiedlichen Paketgrößen
Am Server: /tmp/netio -s
Am Client: 
/tmp/netio -t dein_server

Packet size  1k bytes:  11513 KByte/s Tx,  11441 KByte/s Rx.
Packet size  2k bytes:  11509 KByte/s Tx,  11439 KByte/s Rx.
Packet size  4k bytes:  11508 KByte/s Tx,  11456 KByte/s Rx.
Packet size  8k bytes:  11510 KByte/s Tx,  11451 KByte/s Rx.
Packet size 16k bytes:  11498 KByte/s Tx,  11457 KByte/s Rx.
Packet size 32k bytes:  11492 KByte/s Tx,  11367 KByte/s Rx.
Auch hier sollte total rate bei iptraf immer zwischen 11000-12000 kb/s liegen. Und bei den Ergebnissen sollte bei den unterschiedlichen Paketgrößen keine groben Unterschiede in der Transferrate liegen.

Zum Switch nochmal: evtl. kannst du dir testweise einen anderen Switch leihen, evtl. sogar einen GigaByte-Switch (die kosten ja auch nix mehr). Wobei das eher zum Testen wäre ob bei veränderter Hardware diese Einbrüche/Stockungen auch passieren.

Anbei das Tool netio, zum benutzen halt ausführbar machen 😉
Gepackt als Zip.
Hallöchen,

also ich habe mal deine Tests ausgeführt, danke nochmal:

Eins vorweg: Iptraf lief während der Tests und zeigte keine Einbrüche der Verbindungsgeschwindigkeit.

iperf 
$  iperf -t30 -c 192.168.6.20                                    
------------------------------------------------------------                             
Client connecting to 192.168.6.20, TCP port 5001                                         
TCP window size: 16.0 KByte (default)                                                    
------------------------------------------------------------                             
[  3] local 192.168.6.5 port 45490 connected with 192.168.6.20 port 5001                 
[ ID] Interval       Transfer     Bandwidth                                              
[  3]  0.0-30.1 sec    339 MBytes  94.6 Mbits/sec

$  iperf -t30 -c 192.168.6.20 -d                                 
------------------------------------------------------------                             
Server listening on TCP port 5001                                                        
TCP window size: 85.3 KByte (default)                                                    
------------------------------------------------------------                             
------------------------------------------------------------                             
Client connecting to 192.168.6.20, TCP port 5001                                         
TCP window size: 23.6 KByte (default)                                                    
------------------------------------------------------------                             
[  6] local 192.168.6.5 port 45510 connected with 192.168.6.20 port 5001                 
[  5] local 192.168.6.5 port 5001 connected with 192.168.6.20 port 45040                 
[ ID] Interval       Transfer     Bandwidth                                              
[  6]  0.0-30.0 sec    316 MBytes  88.4 Mbits/sec                                        
[ ID] Interval       Transfer     Bandwidth                                              
[  5]  0.0-30.2 sec    308 MBytes  85.7 Mbits/sec
netio 
$  ./netio -t 192.168.6.20

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size  1k bytes:  11510 KByte/s Tx,  11456 KByte/s Rx.
Packet size  2k bytes:  11518 KByte/s Tx,  11427 KByte/s Rx.
Packet size  4k bytes:  11510 KByte/s Tx,  11455 KByte/s Rx.
Packet size  8k bytes:  11510 KByte/s Tx,  11461 KByte/s Rx.
Packet size 16k bytes:  11472 KByte/s Tx,  11457 KByte/s Rx.
Packet size 32k bytes:  11519 KByte/s Tx,  11384 KByte/s Rx.
Done.
Sieht für mich alles normal aus.
Ich werde mir dann mal morgen irgendwie hier im Haus einen Switch besorgen und schauen,
ob das was ändert.

Grüße,
Vrob
Vrob schrieb Sieht für mich alles normal aus.
Ich werde mir dann mal morgen irgendwie hier im Haus einen Switch besorgen und schauen,
ob das was ändert.
Glaube ich auch nicht, muß also nicht losstürzen 😉
Das wäre eher dann ein Versuch wert, wenn obige Tests z.B. eine AUffälligkeit gezeigt hätten.
GerBra schrieb
Vrob schrieb Sieht für mich alles normal aus.
Ich werde mir dann mal morgen irgendwie hier im Haus einen Switch besorgen und schauen,
ob das was ändert.

Glaube ich auch nicht, muß also nicht losstürzen 😉
Meine Familie wirds schon überleben, mal 5 Minuten ohne Inet zu sein 😉

Grüße,
Vrob
Vrob schrieb Meine Familie wirds schon überleben, mal 5 Minuten ohne Inet zu sein 😉
Du Tyrann! Aber an solchen Aussagen sieht man, wer die Pantoffeln anhatt 😉
So, hier das versprochene, leicht verspätete Update.

Ich habe mir jetzt einen Gigabit-Switch gekauft und den zwischen
PC und Server gehangen. Leder waren die Ergebnisse mit NFS
ziemlich ernüchternd.
Im Grunde war dasselbe Verhalten zu beobachten:
Erst schneller Transfer, dann sinkt die Rate auf knapp 2 MB/s
(das ist ja schonmal ein Fortschritt...) und mittelt sich langfristig
bei ca. 11 MB/s ein.
Nicht unbedingt das, was ich von Gigabit erwartet hätte 😉

Gut, es waren relativ alte CAT5 Kabel im Spiel, aber ein kurzer
Test mit Samba zeigte konstante Raten von 35 MB/s, was schon-
mal ganz annehmbar ist.

Irgendwo ist also der Wurm bei NFS drin. Letztendlich kann
ich mich aber auch mit Samba anfreunden, da ich sowieso
ein heterogenes Netzwerk habe und eh nicht um die Einrichtung
von Samba herumgekommen wäre.
Ich dachte nur eben, NFS könnte einen Geschwindigkeits-
vorteil bringen 😉

Grüße,
Vrob
Wir hatten in der Schule auch mit ganz ähnlichen Problemen zu kämpfen. Ein SuSE-Server sollte 17 Clientrechner per Netzwerk mit einem speziellen SuSE-System booten. Wenn man sich die Netzauslastung auf dem Server angeschaut hat, war er immer nur zeitweise voll ausgelastet.
Ich kann ja mal fragen, ob da irgendein Problem gefunden wurde.
Vrob schrieb Im Grunde war dasselbe Verhalten zu beobachten:
Erst schneller Transfer, dann sinkt die Rate auf knapp 2 MB/s
(das ist ja schonmal ein Fortschritt...) und mittelt sich langfristig
bei ca. 11 MB/s ein.
Nicht unbedingt das, was ich von Gigabit erwartet hätte 😉
Dieses beobachtete Verhalten ist wie gesagt IMHO vollkommen normal und pendelt sich im Mittel eben doch bei der max. Übertragungsrate ein. Den größten Vorteil des anfänglichen "schnellen" Transfers haben Vorgänge aus dem nomalen Alltag (außer du würdest immer/nur "große" Dateien kopieren)

Allerdings ist 11Mb/s (und auch die 35Mb/s später beim SMB/Cifs) für Gigabyte-Ethernet ja nicht berauschend, wobei das viele Ursachen (und bei GigaByte eben auch die Festplatten) sein können.

Noch mal ein Test. Dieser misst den Transfer ohne den Einfluß von HD-IO und Filesystems auf beiden Seiten, also auch ohne das Caching. Du brauchst auf beiden Systemen das Paket gnu-netcat.
Auf beiden Seiten mußt du kein root sein.
Am Server: 
netcat -t -p 6666 -l > /dev/null
Am Client: 
dd if=/dev/zero | pv | netcat dein_rechner 6666
Hier werden jetzt "Daten" nur von/nach Pseudo-Devices gelesen/geschrieben, IO spielt also zu keiner Zeit eine Rolle. Abbrechen am Client mit STRG+C, damit beendet sich auch der lauschende netcat am Server.
Außerdem lohnt es sich ggf. auch mal den Spieß umzudrehen, also den Listener am Client zu starten.
Du solltest hier konstant und von Anfang an die maximal mögliche Transferrate haben.
Soso,

was ich mit dem von dir gequoteten Text sagen wollte, war eigentlich nur, dass sich das Problem durch einen neuen Switch nicht wirklich in Luft aufgelöst hat 😉

Dann habe ich auch mal die von dir vorgeschlagenen Tests ausgeführt:

Vom Client auf den Server: ~ 85 MB/s
Vom Server auf den Client: ~ 35 MB/s

Das ist ja doch ein recht großer Unterschied, aber andererseits ist auch der Via C7 Prozessor recht schwachbrüstig. Ebenso ist die Via Velocity sicherlich nicht die High-End-Server NIC, aber ob diese beiden Faktoren derart entscheidenen Einfluss auf die Performance haben, kann ich nicht sagen.

Was mir aber noch interessantes aufgefallen ist:
Trotz Gigabit Switch erhalte ich am Client folgende mii-tool Ausgabe: 
$ mii-tool -v eth0
eth0: negotiated 100baseTx-FD flow-control, link ok
  product info: vendor 00:07:32, model 17 rev 2
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
  link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
Eigentlich hätte ich hier 1000baseT-FD erwartet, so wie das auch am Server der Fall ist.

Ebenso zeigt mir iperf folgendes an:
$  iperf -t30 -c 192.168.6.20                                                                                                                                     
------------------------------------------------------------                                                                                                                              
Client connecting to 192.168.6.20, TCP port 5001                                                                                                                                          
TCP window size: 16.0 KByte (default)                                                                                                                                                     
------------------------------------------------------------                                                                                                                              
[  3] local 192.168.6.5 port 60323 connected with 192.168.6.20 port 5001                                                                                                                  
[ ID] Interval       Transfer     Bandwidth                                                                                                                                               
[  3]  0.0-30.0 sec  3.29 GBytes    941 Mbits/sec
Hier erstmal angesichts eines mit Pflaster geflickten, mehrere Jahre alten Cat5-Kabels und der
low budget Netzwerkkarten kein übermäßig ernüchterndes Ergebnis.

Aber das hier macht mich ein bisschen stutzig:
$ iperf -t30 -c 192.168.6.20 -d                                                                                                                                  
------------------------------------------------------------                                                                                                                              
Server listening on TCP port 5001                                                                                                                                                         
TCP window size: 85.3 KByte (default)                                                                                                                                                     
------------------------------------------------------------                                                                                                                              
------------------------------------------------------------                                                                                                                              
Client connecting to 192.168.6.20, TCP port 5001                                                                                                                                          
TCP window size: 16.0 KByte (default)                                                                                                                                                     
------------------------------------------------------------                                                                                                                              
[  5] local 192.168.6.5 port 60329 connected with 192.168.6.20 port 5001                                                                                                                  
[  4] local 192.168.6.5 port 5001 connected with 192.168.6.20 port 52567
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-30.0 sec  1.80 GBytes    515 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-30.0 sec  1.24 GBytes    355 Mbits/sec
Bei Full-Duplex hätte ich jetzt eigentlich ~950 MBit/s in beide Richtungen erwartet, so wie 100 Mbit Ethernet auch der Fall ist. Der Switch unterstützt das laut Verpackung auch 😉

Ein bisschen seltsam finde ich auch, dass ich im Vergleich zwischen netcat und SMB/cifs über die Hälfte an Performance verliere. Die Festplatten beider Systeme sind zwar 256 Bit verschlüsselt, aber der Client liest für Performancetests ja aus /dev/zero und der Cryptoprozessor des Epia Boards im Server leistet auch beste Dienste:
dd if=/dev/zero of=foo.dat bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1,0 GB) copied, 12,6015 s, 83,2 MB/s
Allerdings sagt top während eines Transfers über Samba, dass hauptsächlich auf IO gewartet wird (~40-50% wai).

Grüße,
Vrob