Also die Frage nach meinem Problem mit Gigabit-LAN wurde leider nicht gelöst. Wie in Foren üblich hagelte es erstmal Standardantworten („Kabel“, „Treiber“) und Fragen nach mehr Informationen. Ich weiß nicht woher dieses Verhalten kommt …
Ist ja bestimmt lieb gemeint, wenn aus Interesse nochmal nachgefragt wird, aber das Problem ist eine asymmetrische Datenübertragungsrate und wenn man keine Ahnung hat wie das zustande kommen kann, wie sollen einem Helfer dann weitere Informationen helfen? Vielleicht so ein Reflex aus der Schulzeit: eigentlich enthält die Textaufgabe alles wichtige, aber der Schüler weiß den Lösungsweg nicht und fragt lieber nochmal nach mehr Informationen … wer weiß ;-)
So, meine ganz eigene und total schwachsinnige Theorie ist nun, dass die Daten in die eine Richtung bergauf fließen und somit in die andere Richtung bergab. Hab auf dem Windowsrechner übrigens noch eine Linux-Live-CD ausprobiert, auch damit ist die Übertragungsrate asymmetrisch. Liegt definitiv daran, dass sich das Linux auf der VDR-Kiste irgendwie schlafen legt bzw. – wie vermutet – auf ACKs wartet statt die Leitung vollzupumpen, wenn es Daten senden soll.
Wie auch immer … knapp 20 MB/s ist immerhin doppelt so schnell wie vorher und anders herum klappt’s ja. Ich kümmere mich erstmal nicht mehr darum, aber falls doch noch jemandem was einfällt, der dieses Problem kennt und nicht nur seine Glaskugel befragt (ich hab sowieso eine bessere) … bitte, Hilfe! ;-)
Lösung:
Es war ein Treiberproblem. Hab mir von Realtek den entsprechenden Treiber für den R8169 Chip geladen, kompiliert und installiert und schwupps kann auch die Linuxkiste die Leitung sättigen. Scheinbar wird bei OpenSuse 10.2 bzw. Kernel 2.6.18 ein veralteter Treiber mitgeliefert. Jetzt geht’s auf jeden Fall!
Kommentare
10 Antworten zu „Das asymmetrische LAN wieder“
Vielleicht liegt es an der Kernel-Version:
http://osdir.com/ml/network.general/2004-08/msg00043.html
Ich sehe gerade das „Die reine Übertragungsgeschwindigkeit ist mit Linux als Sender nur bei 17 MB/s und mit Windows als Sender bei knapp 70 MB/s.“
Was ja die Theorie, dass Linux zu lange braucht um die ACK´s zu senden falsch ist. Windows sendet die ACK´s zu langsam oder gar nicht.
Kannst du die Festplatte ausschließen? Versuch mal von /dev/urandom oder /dev/zero zu lesen und schieb das ins netz.
Linux sendet immer nur eine bestimmte Anzahl an Datenpaketen raus ohne ein ACK bekommen zu haben. Ich würde diesen Wert mal drastisch erhöhen, allerdings weiß ich nicht, wo das geht ;)
wo isn der simpsonsfilmbericht???
^^
Der Poster auf osdir.com hatte nur ein Problem mit QOS. Hab’s sicherheitshalber nochmal überprüft, aber habe da nichts aktiviert.
Die Festplatte kann ich ausschließen, da der Traffic nur mit NetIO gemessen wurde, das nicht auf die Festplatte zugreift.
Und deine letzten beiden Sätze erfassen exakt das Problem. Linux wartet zu lange, während Windows nicht auf ACKs wartet.
btw die Performance nochmal mit iPerf gemessen:
Von Windows zu Linux (wie man sieht, kann Windows die Leitung komplett sättigen):
Von Linux zu Windows klappt das nicht:
Auf dem Client lautete der Befehl: „iperf -l 256K -w 8192K -c IP“
Die unterschiedlichen „read lengths“ am Ende sagen vielleicht irgendwas aus … keine Ahnung. Ich hab auch schon alle Parameter verdreht, die man verdrehen kann. Vielleicht mache ich doch mal ein Kernelupdate *kotz*
Hab nochmal mit Ethereal „gemessen“. Linux als Sender interessiert sich gar nicht was ich als Windowsize dem iPerf Programm übergebe, d.h. nur bei Werten unterhalb von 8 KB, alle Werte darüber sind dann trotzdem nur 8 KB … für Gigabit müsste aber die Windowsize bei einer RTT von 300 µs um die 40 KB groß sein damit die Leitung immer gefüllt ist und das erklärt dann auch warum es hier nur ca. 1/5 des eigentlichen Wertes erreicht.
Nur bringt ein Verstellen der entsprechenden Parameter im Kernel überhaupt nichts. Nichts ändert sich … grmpf!
Und da kommentiere ich mich noch ein viertes Mal in Folge …
Habe mich am Ende doch dazu aufgerafft den Kernel bzw. das Modul für den Realtek Chip (R8169) auf der Netzwerkkarte neu zu kompilieren und zwar mit den aktuellen Sourcen von Realtek selbst. Und siehe da, es funktioniert jetzt alles (siehe Artikeltext), aber ich hab bestimmt ein paar graue Haare mehr :-/
subber !!!
Gerade rechtzeitig zum Sysadmin-Schulterklopf-Tag … gelle ;-)
[…] hat nach einem Review des Simpsonsfilms gefragt. Meine Sternchen (9 von 10) habe ich schon am Premierenabend vergeben, aber gut, schreibe ich noch […]