Realtek NIC nur 100 Mbit/s

[daniel7558]

Hallo,
ich versuche ein NAS aufzusetzen (openmediavault) und habe mit Debian große Probleme die Netzwerkkarten richtig zum Laufen zu bekommen. Unter Ubuntu und FreeBSD funktioniert es out of the box.
Das Problem bestand zuerst darin, dass ich trotz Gigabit Netzwerk nur eine Geschwindigkeit von 100 Mbit/s bekomme. Das war (höchstwahrschienlich) einem Hardware Defekt am Router geschuldet, der nun behoben ist. Ich habe dann eine Geschwindigkeit von 1000 Mbit/s bekommen, jedoch war es nicht möglich größere Dateien mit dieser Geschwindigkeit zu transferieren, da nach einigen Sekunden die Netzwerkverbindung komplett einbrach (auf ein paar KB/s).
Es sind zwei Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller verbaut.

Zum Hardwaredefektproblem habe ich bereits in diesem Forum gefragt und zu dem Dateitransferproblem habe ich auch im openmediavault Forum ein Thema erstellt, wobei wir da keine Lösung gefunden haben.
Die Links zu den beiden wären:
viewtopic.php?t=162309
http://forum.openmediavault.org/index.p ... -transfer/

Ich verzichte in diesem Post darauf sämtliche Terminal Ausgaben hinzuzufügen, da das sehr schnell sehr unübersichtlich werden würde und dies bereits in den anderen zwei Topics enthalten ist.

Ich wäre jedem sehr dankbar, der sich kurz die Zeit nehmen würde um einen Blick auf das Problem zu werfen, da ich wirklich keine Ideen mehr habe, woran es liegen könnte.
Aktuell ist Debian 8.6.0 nonfree installiert und laut iperf3 ist die Verbindung nur 100 Mbit/s (ethtool meldet Gigabit full duplex).

Viele Grüße,
Daniel

[DeletedUserReAsG]

Die Ausgabe von ifconfig für das betreffende Interface, nachdem das Problem aufgetreten ist, könnte Hinweise liefern.

[daniel7558]

Danke für die Antwort.
Du meinst nachdem die Netzwerkverbindung einbricht? Das passiert nur unter Debian 7.x. Bei Debian 8.x ist es auf 100 Mbit limitiert, jedoch stabil. Wenn das das ist, was du meinst, installier ich schnell 7.x und teste es.

Bei Debian 8.6.0 ergibt ifconfig:

Code: Alles auswählen

root@debian:/home/daniel# ifconfig
eth0      Link encap:Ethernet  Hardware Adresse 00:01:2e:6e:b2:e2
          inet Adresse:192.168.1.250  Bcast:192.168.1.255  Maske:255.255.255.0
          inet6-Adresse: fe80::201:2eff:fe6e:b2e2/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:5030109 errors:0 dropped:0 overruns:0 frame:0
          TX packets:886192 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:7593356493 (7.0 GiB)  TX bytes:47884493 (45.6 MiB)

lo        Link encap:Lokale Schleife
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX packets:43 errors:0 dropped:0 overruns:0 frame:0
          TX packets:43 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:6695 (6.5 KiB)  TX bytes:6695 (6.5 KiB)

[DeletedUserReAsG]

Wenn das das ist, was du meinst, installier ich schnell 7.x und teste es.

Ja – um den Fehler zu suchen, wäre die Ausgabe von dem System mit dem Fehler schon recht praktisch …

[daniel7558]

Die Ausgabe von ifconfig zuvor:

Code: Alles auswählen

root@openmediavault:~# ifconfig
eth0      Link encap:Ethernet  Hardware Adresse 00:01:2e:6e:b2:e2
          inet Adresse:192.168.1.250  Bcast:192.168.1.255  Maske:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:1988 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4143 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:925506 (903.8 KiB)  TX bytes:5371011 (5.1 MiB)
          Interrupt:135 Basisadresse:0x8000

lo        Link encap:Lokale Schleife
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Ausgabe von ifconfig nach dem Auftreten des Fehlers:

Code: Alles auswählen

root@openmediavault:~# ifconfig
eth0      Link encap:Ethernet  Hardware Adresse 00:01:2e:6e:b2:e2
          inet Adresse:192.168.1.250  Bcast:192.168.1.255  Maske:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:74163833 errors:1 dropped:3 overruns:0 frame:4
          TX packets:21679876 errors:0 dropped:47 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:110794907308 (103.1 GiB)  TX bytes:2844779209 (2.6 GiB)
          Interrupt:135 Basisadresse:0x8000

lo        Link encap:Lokale Schleife
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

[DeletedUserReAsG]

Das sieht soweit okay aus. Ich würde nun die Latenz zwischen beiden Geräten während des Einbruchs beobachten, und wenn die RTT sich nicht deutlich ändert, den Fehler beim Wegschreiben der Daten weitersuchen – ich weiß ja nun nicht, was für eine Maschine das ist, und ob sie in der Lage wäre, knapp 120MB/s wegzuschreiben (ein Atom, der das in einen dm-crypt-Container schreiben soll, würde z.B. nach dem Vollschreiben des Buffers auf beschriebene Weise einbrechen). Hilfreich zum Schauen mag iotop sein, außerdem könnte man mal Daten über’s Netz schicken und ohne Umweg nach /dev/null ausgeben, um zu schauen, ob es daran liegen mag.

[daniel7558]

Um die Latenz zu messen, habe ich den Rechner durchgehend anpingen lassen und das sieht für mich ganz in Ordnung aus. Bei der Zeitüberschreitung bricht dann alles plötzlich ein.

Code: Alles auswählen

...
Antwort von 192.168.1.250: Bytes=32 Zeit=3ms TTL=64
Antwort von 192.168.1.250: Bytes=32 Zeit=5ms TTL=64
Antwort von 192.168.1.250: Bytes=32 Zeit=14ms TTL=64
Antwort von 192.168.1.250: Bytes=32 Zeit=13ms TTL=64
Antwort von 192.168.1.250: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.1.250: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.250: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.1.250: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.1.250: Bytes=32 Zeit=6ms TTL=64
Antwort von 192.168.1.250: Bytes=32 Zeit=12ms TTL=64
Antwort von 192.168.1.250: Bytes=32 Zeit=4ms TTL=64
Antwort von 192.168.1.250: Bytes=32 Zeit=14ms TTL=64
Antwort von 192.168.1.250: Bytes=32 Zeit=10ms TTL=64
Antwort von 192.168.1.250: Bytes=32 Zeit=6ms TTL=64
Antwort von 192.168.1.250: Bytes=32 Zeit=15ms TTL=64
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Der Rechner wäre in der Lage 120MB/s zu schreiben. Es ist eine SSD verbaut und der Intel Celeron N3150 (Quadcore 1,6 - 2Ghz) sollte da auch keine großen Probleme bereiten.
Getestet habe ich nun mit wget und einer 2 GB großen Datei die über http von einer Ramdisk geladen wird. Nach drei Downloads trat der Fehler auf.

Code: Alles auswählen

root@openmediavault:~# wget http://192.168.1.106:8080/Downloads.tar
--2016-10-31 22:58:07--  http://192.168.1.106:8080/Downloads.tar
Verbindungsaufbau zu 192.168.1.106:8080... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 2147747840 (2,0G) [application/x-tar]
In »»Downloads.tar«« speichern.

100%[====================================>] 2.147.747.840  105M/s   in 24s

2016-10-31 22:58:31 (85,6 MB/s) - »»Downloads.tar«« gespeichert [2147747840/2147                                                                  747840]

root@openmediavault:~# for i in {1..10}; do wget http://192.168.1.106:8080/Downl                                                                  oads.tar; done
--2016-10-31 23:00:04--  http://192.168.1.106:8080/Downloads.tar
Verbindungsaufbau zu 192.168.1.106:8080... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 2147747840 (2,0G) [application/x-tar]
In »»Downloads.tar.1«« speichern.

100%[====================================>] 2.147.747.840  101M/s   in 25s

2016-10-31 23:00:29 (81,0 MB/s) - »»Downloads.tar.1«« gespeichert [2147747840/21                                                                  47747840]

--2016-10-31 23:00:29--  http://192.168.1.106:8080/Downloads.tar
Verbindungsaufbau zu 192.168.1.106:8080... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 2147747840 (2,0G) [application/x-tar]
In »»Downloads.tar.2«« speichern.

100%[====================================>] 2.147.747.840 97,9M/s   in 21s

2016-10-31 23:00:50 (99,8 MB/s) - »»Downloads.tar.2«« gespeichert [2147747840/21                                                                  47747840]

--2016-10-31 23:00:50--  http://192.168.1.106:8080/Downloads.tar
Verbindungsaufbau zu 192.168.1.106:8080... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 2147747840 (2,0G) [application/x-tar]

iotop zeigte dabei keine Auffälligkeiten an und schrieb immer ungefähr mit der Geschwindigkeit der Übertragung

Code: Alles auswählen

Total DISK READ:       0.00 B/s | Total DISK WRITE:     123.55 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
  248 be/3 root        0.00 B/s  635.30 M/s  0.00 % 36.82 % [jbd2/sda1-8]
  846 be/4 root        0.00 B/s    0.00 B/s  0.00 % 28.37 % [flush-8:0]
 3096 be/4 root        0.00 B/s   53.15 M/s  0.00 %  0.00 % wget http://192.168.1.106:8080/Downloads.tar
 1992 be/4 root        0.00 B/s   11.58 K/s  0.00 %  0.00 % rsyslogd -c5
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init [2]
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
    6 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/0]
    7 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [watchdog/0]
    8 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/1]
   10 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/1]
   11 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/0:1]
   12 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [watchdog/1]
   13 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/2]
.......

In einem weiteren Versuch habe ich noch die RAM Auslastung bis zum Fehler beobachtet. Zu Beginn hatte er ca. 7.5 GB frei und als der Fehler auftrat waren noch ca. 5 GB frei (von insgesamt 8 GB). Dieses mal brach die Verbindung aber schon beim ersten Download der Datei ab. Sieht für mich so aus als wäre die Datei komplett im RAM behalten worden (ist das so gewünscht?).