CodingBox Q&A Ask question

Ein Port eines X520-DA2 schafft in iperf3 nur noch 1 Gbit/s nach dem Umzug von TrueNAS Core auf SCALE 24.10

Asked Active Viewed 19 AI translation from English
0

Die Storage-Box ging von Core 13.0-U6.7 auf SCALE 24.04 und dann weiter auf 24.10, und seitdem kriecht ein Port dahin, während sein Zwilling auf derselben Karte völlig zufrieden ist. Die 25G-Karte macht dasselbe, und genau das lässt mich an meinen eigenen Augen zweifeln.

  • Intel X520-DA2 mit Intel Multimode-SFP+-Optik, 10G zum Switch
  • Intel XXV710-DA2 mit Intel SFP28-Optik, 25G zum selben Switch
  • TrueNAS SCALE 24.10 auf dem NAS (war Core 13.0-U6.7, dann 24.04)
  • iperf3 zwischen dem NAS und einem Client als Maßstab

Der Link-Status am langsamen Port sieht genau so aus, wie er soll:

$ ethtool enp1s0f0 | grep -E 'Speed|Duplex|Link detected'
    Speed: 10000Mb/s
    Duplex: Full
    Link detected: yes

$ iperf3 -c 192.168.3.2
# parks itself around 1 Gbit/s for the whole run
# the second port of the same card does line rate against its own client

Schon gemacht:

  • die Optiken zwischen den beiden Ports der Karte getauscht; der langsame Port blieb langsam, der schnelle blieb schnell
  • sysctl net.ipv4.tcp_congestion_control auf beiden Seiten verglichen, gleicher Wert
  • beide Enden neu gesteckt und die Ferrulen gereinigt

Alles, was sich auf der Link-Ebene messen lässt, sagt 10G und 25G Vollduplex, und die Nutzlast klebt trotzdem bei ungefähr einem Gigabit. Bauen die Module ab, gibt die NIC den Geist auf, oder schaue ich auf die falsche Ebene?

Comments 3

Accepted answer

Die Optik hast du selbst schon ausgeschlossen: du hast sie zwischen den Ports getauscht, und die Langsamkeit blieb beim Port. Also die Module in Ruhe lassen und Link-Layer-Fakten von Durchsatzzahlen trennen, die beantworten nämlich unterschiedliche Fragen.

Zwei Dinge unterscheiden sich normalerweise zwischen einem schnellen und einem langsamen Port auf derselben Karte. Zusammen ansehen:

ip -d link show enp1s0f0
ip -d link show enp1s0f1

Sitzt einer bei MTU 1500 und der andere bei 9014, und liegen sie in unterschiedlichen VLANs, dann geht dein langsamer Test nicht aus der NIC raus und wieder rein, sondern durch den Routing-Pfad des Hosts. Einen Client ins gleiche VLAN und Subnetz wie der langsame Port stellen und iperf3 -c dagegen laufen lassen. Kein Router im Pfad, kein MTU-Mismatch, nichts zum Diskutieren.

Bringt der Test im einzelnen VLAN Line-Rate, sind Port und Transceiver in Ordnung, und was du eigentlich gemessen hast, ist die Inter-VLAN-Routing-Performance auf dem Host, und genau da landet ein ordentlicher Teil der Core-zu-SCALE-Umzüge: das Forwarding zwischen VLANs ist spürbar schlechter als unter Core.

Das ist eine Diagnose und keine wirkliche Heilung. Den größten Teil bekommst du zurück, indem du die schweren Flows innerhalb eines VLANs hältst oder das Routing dem Switch statt dem NAS überlässt. Zumindest hindert es dich daran, zwei völlig gesunde SFP+-Module zurückzuschicken.

3 Ukrainerxnode71UA Show original (English) AI translation

Bevor jemand anfängt, Optik rauszuziehen: was sagt der Switch zu den beiden Ports? Ausgehandelte Geschwindigkeit, Duplex und die Fehlerzähler bei beiden. Und welches Ende fährt im langsamen Test den iperf3-Server - bleibt die Deckelung, wenn du die Richtung umdrehst und von der anderen Seite drückst?

Dann MTU und VLAN vom langsamen und vom schnellen Port nebeneinander posten. Ein Port, der 10G aushandelt und nur ein Gigabit Nutzlast bewegt, ist fast immer ein Forwarding- oder Pfad-Problem, kein optisches. Sitzen die beiden Ports nicht im selben VLAN, bewertet iperf3 deinen Router, nicht deinen Link.

3 United StateslasernodeUS Show original (English) AI translation

Andere Hardware, gleiches Muster. Zwei Boxen Rücken an Rücken auf X520-DA-Karten über ein SFP+ DAC, auf der einen Seite Hyper-V Server Core 2012 R2, auf der anderen eine NAS4Free-9.1-Storage-Box. Direkt durch schaffte das Paar 8-9 Gbit/s beim Lesen und Schreiben. In dem Moment, in dem der Port an einen Hyper-V-Virtual-Switch gebunden wurde, fiel es auf etwa 500 Mbit/s, und die Karten unter Windows Server 2012 R2 und Windows 8.1 erneut zu testen, änderte gar nichts.

Bewiesen wurde es nie. Die eine Antwort, die ich bekam, fragte, welche Platten und welches RAID-Level hinter jedem Ende steckten, eine faire Frage, denn der Storage kann die Deckelung sein, lange bevor es der 10G-Pfad ist. Die Angewohnheit, die ich daraus mitgenommen habe: denselben Link mit angehängter und mit abgehängter Extra-Schicht messen, und wenn möglich gegen eine RAM-Disk. Das Kabel und die Karten waren dort auch nicht das Problem.

3 VietnamdwdmpilotVN Show original (English) AI translation
Log in to comment. Log in