Das asymmetrische LAN wieder

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!


Beitrag veröffentlicht

in

,

von

Schlagwörter:

Kommentare

10 Antworten zu „Das asymmetrische LAN wieder“

  1. Avatar von der Flo

    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 ;)

  2. Avatar von Steffi

    wo isn der simpsonsfilmbericht???
    ^^

  3. Avatar von Sebbi

    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.

  4. Avatar von Sebbi

    btw die Performance nochmal mit iPerf gemessen:

    Von Windows zu Linux (wie man sieht, kann Windows die Leitung komplett sättigen):

    refrigerator:~ # iperf -i 1 -l 256K -w 8192K -m -s -N
    ————————————————————
    Server listening on TCP port 5001
    TCP window size: 16.0 MByte (WARNING: requested 8.00 MByte)
    ————————————————————
    [ 4] local 192.168.1.10 port 5001 connected with 192.168.1.100 port 3232
    [ ID] Interval Transfer Bandwidth
    [ 4] 0.0- 1.0 sec 110 MBytes 923 Mbits/sec
    [ 4] 1.0- 2.0 sec 115 MBytes 968 Mbits/sec
    [ 4] 2.0- 3.0 sec 115 MBytes 969 Mbits/sec
    [ 4] 3.0- 4.0 sec 115 MBytes 967 Mbits/sec
    [ 4] 4.0- 5.0 sec 115 MBytes 966 Mbits/sec
    [ 4] 5.0- 6.0 sec 113 MBytes 949 Mbits/sec
    [ 4] 6.0- 7.0 sec 114 MBytes 959 Mbits/sec
    [ 4] 7.0- 8.0 sec 113 MBytes 949 Mbits/sec
    [ 4] 8.0- 9.0 sec 112 MBytes 940 Mbits/sec
    [ 4] 9.0-10.0 sec 115 MBytes 961 Mbits/sec
    [ 4] 0.0-10.3 sec 1.12 GBytes 935 Mbits/sec
    [ 4] MSS size 4460 bytes (MTU 4500 bytes, unknown interface)
    [ 4] Read lengths occurring in more than 5% of reads:
    [ 4] 4460 bytes read 95700 times (54.2%)
    [ 4] 8920 bytes read 74608 times (42.2%)

    Von Linux zu Windows klappt das nicht:

    C:\Tools\iPerf>iperf -i 1 -l 256K -w 8192K -m -s -N
    ————————————————————
    Server listening on TCP port 5001
    TCP window size: 8.00 MByte
    ————————————————————
    [1908] local 192.168.1.100 port 5001 connected with 192.168.1.10 port 35644
    [ ID] Interval Transfer Bandwidth
    [1908] 0.0- 1.0 sec 18.9 MBytes 159 Mbits/sec
    [1908] 1.0- 2.0 sec 18.9 MBytes 159 Mbits/sec
    [1908] 2.0- 3.0 sec 19.0 MBytes 159 Mbits/sec
    [1908] 3.0- 4.0 sec 18.9 MBytes 158 Mbits/sec
    [1908] 4.0- 5.0 sec 18.9 MBytes 158 Mbits/sec
    [1908] 5.0- 6.0 sec 18.9 MBytes 158 Mbits/sec
    [1908] 6.0- 7.0 sec 19.1 MBytes 160 Mbits/sec
    [1908] 7.0- 8.0 sec 18.7 MBytes 157 Mbits/sec
    [1908] 8.0- 9.0 sec 19.0 MBytes 159 Mbits/sec
    [1908] 9.0-10.0 sec 18.9 MBytes 158 Mbits/sec
    [1908] 0.0-10.6 sec 202 MBytes 159 Mbits/sec
    [1908] MSS and MTU size unknown (TCP_MAXSEG not supported by OS?)
    [1908] Read lengths occurring in more than 5% of reads:
    [1908] 288 bytes read 538 times (33.8%)
    [1908] 262144 bytes read 756 times (47.5%)

    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*

  5. Avatar von Sebbi

    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!

  6. Avatar von Sebbi

    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 :-/

  7. Avatar von Christoph
    Christoph

    subber !!!

  8. Avatar von Sebbi

    Gerade rechtzeitig zum Sysadmin-Schulterklopf-Tag … gelle ;-)

  9. […] hat nach einem Review des Simpsonsfilms gefragt. Meine Sternchen (9 von 10) habe ich schon am Premierenabend vergeben, aber gut, schreibe ich noch […]