☰

Kurzfassung

tag-icon • tag-icon ethernet throughput
Kurzfassung

Kurzfassung

Mein Heimnetzwerk ist reines Gigabit mit Geräten, die alle Jumbo-Frames bis zu mindestens ~9000 Bytes unterstützen. Eine Erhöhung der MTU-Jumbo-Frame-Einstellung auf der Synology auf 6000 (Bytes) steigert die Leistung (810 Mbit/s Schreiben und 945 Mbit/s Lesen). Eine Einstellung auf 7000 zerstört nur die Leseleistung (die bis auf 4 Mbit/s absinkt); die Schreibleistung bleibt schnell.

Dies ist unerwartet, da die meisten Jumbo-Frame-Probleme keine Richtung haben und typischerweise alles oder nichts sind (Pakete werden an einem Switch verworfen, egal woher sie kamen). Es scheint keinebeliebigEs findet überhaupt eine IP-Fragmentierung statt, aber die TCP-Schicht ist wirklich unglücklich. Was könnte dieses asymmetrische/unzuverlässige Verhalten verursachen und wie kann ich es beheben, um die volle 9000-Byte-MTU zu unterstützen, die alle meine Geräte unterstützen sollen?

Lange Version

Dies sind meine bearbeiteten Notizen, die ich gemacht habe, während ich versucht habe, dies herauszufinden.

Klient

Realtek PCIe GBE Family Controller RTL8167
Jumbo Frame: 9 KB MTU

$ netsh interface ipv4 show subinterfaces
   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
  9198                1   32501506   11275394  Local Area Connection

(scheint, als ob 9198 den 14-Byte-Ethernet-Header nicht enthält)

$ ping -l 1500 -f 192.168.1.84

(beobachtet mit Wireshark auf dem Client; alle Größen sind Wire-Byte-Größen)
[9213, ∞] nicht vom Host gesendet (würde Fragmentierung erfordern)
[9019, 9212] gesendet, aber keine Antwort
[9015, 9018] fragmentierte IP-Antwort
[42, 9014] unfragmentierte IP
[0, 41] ? (kann nicht generiert werden, da eth+IP+ICMP-Header = 14+20+8 = 42 Bytes)

Router (Switch-Teil)

Asus RT-AC68U -- Firmware 3.0.0.4.378_4585
Jumbo Frame aktivieren: "Aktivieren"
Kann nicht herausfinden, welche Jumbo-Frame-Größe es tatsächlich unterstützt, scheint mindestens 9000 zu sein

Es fragmentiert Ping-Anfragen vom Client auf genau 1514 Byte (aber das Pingen des Routers löst möglicherweise dessen WAN-Router-Verhalten statt dessen LAN-Switch-Verhalten aus?)

Nicht verwalteter Switch

TP-LINK TL-SG1008D
Jumbo Frames (Datenblätter): 9 KB (auf der Website steht 15 KB, aber es sieht aus wie ein anderes Gerät)

Server

Synology DS1815+ – DSM 5.2-5565 Update 1
Jumbo-Frame: 9000

Dateilesepakete von Synology zum Client
Größe: die meisten sind 9014 Bytes (in beide Richtungen)
IP-Flags: Nicht fragmentieren
Wireshark hat Folgendes entdeckt: TCP Spurious Retransmission, TCP Vorheriges Segment nicht erfasst, TCP Out-Of-Order, TCP Fast Retransmission und normale (9014 Byte) Pakete
SMB2-over-NetBIOS-Protokollpakete Leseantwort Leselänge: 65.536 (~8 TCP-Segmente)

$ ifconfig
bond0     Link encap:Ethernet  HWaddr --:FF
          inet addr:192.168.1.84  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addrs: --/64 Scope:Link, --/64 Scope:Global, --/64 Scope:Global
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:85 dropped:0 overruns:0 frame:85
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:237 GiB  TX bytes:117 GiB

eth2      Link encap:Ethernet  HWaddr --:00
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:19 dropped:0 overruns:0 frame:19
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:236 GiB  TX bytes:83 GiB

eth3      Link encap:Ethernet  HWaddr --FF
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:66 dropped:0 overruns:0 frame:66
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1 GiB  TX bytes:33 GiB

eth2 und eth3 sind mittels Adaptive Load Balancing verbunden (keine Switch-Unterstützung)

$ ping -c 5 -s 1500 192.168.1.82

(beobachtet mit Wireshark auf dem Client; alle Größen sind Wire-Byte-Größen)
[9019, ∞] Anfrage gesendet, Antwort gesendet, Antwort nicht empfangen
[9015, 9018] fragmentierte IP-Anfrage (wahrscheinlich fragmentiert durch Synology, Busybox-Ping hat keine Option ohne Fragmentierung, daher ist es schwer zu sagen)
[60, 9014] unfragmentierte IP
[0, 59] ? (kann nicht generiert werden, da Busybox-Ping mindestens 18 Bytes plus die 42 Byte-Header eingibt)

Sonstige Daten

  • Das Heruntersetzen der Client-MTU auf 8 KB hat nicht geholfen
  • Die Lesegeschwindigkeit des Servers sinkt drastisch, wenn die MTU des Servers von 6000 (großartig, 945 Mbit/s) auf 7000 (schrecklich, 4 Mbit/s) geändert wird.
  • Die Schreibgeschwindigkeit des Servers bleibt grundsätzlich bei allen MTU-Einstellungen des Servers unverändert (immer zwischen 700 und 825 Mbit/s)
  • Die Synology verfügt über ein gebündeltes Netzwerk (2 der 4 Ports)
  • Alle Kabel sind Cat6 oder Cat5e

Antwort1

Aktualisieren der Firmware

Meiner Erfahrung nach behebt Synology in jeder Firmware-Version viele Probleme, und die Version, die Sie verwenden, ist fast vier Jahre alt. Ich habe die Versionshinweise nicht gelesen, aber es scheint viele Möglichkeiten zu geben, dass ein Jumbo-Frame-Fehler seitdem behoben wurde.

Testen mit einer Direktverbindung

Verbinden Sie Ihre Testmaschine mit neuen Patchkabeln direkt mit der Synology (weisen Sie statische IPs im selben Subnetz zu) und führen Sie Ihre Tests erneut aus. Dadurch werden die Verkabelung und die Switches sowie alle anderen Geräte- und Konfigurationsprobleme behoben. Wenn das Problem weiterhin besteht, führen Sie Ihre Tests mit einem anderen Computer aus. Wenn es weiterhin besteht, liegt es sicherlich am NAS.

Wenn das Problem während des Direktverbindungstests behoben wird, versuchen Sie zuerst, den Switch und dann die Verkabelung auszutauschen. Sie haben die Verbindungen nicht angezeigt, daher gehe ich davon aus, dass nur der TPLINK zwischen der Testmaschine und dem NAS vorhanden ist.

verwandte Informationen