CodingBox Q&A Ask question
Log in Sign up

MCX516A-CCAT-Mesh über 100G-DAC: lshw sagt 40Gbit/s, und ein einzelner iperf3-Stream deckelt bei 21 Gbit/s

Asked Active Viewed 49 AI translation from English
2

Wir betreiben einen Drei-Knoten-Cluster, dessen Knoten direkt über 100G-DAC miteinander verkabelt sind, kein Switch im Pfad, und die Interfaces stecken in einem Broadcast-Bond, damit der Replikations-Traffic sein eigenes Fabric hat. Bevor ich echte Last draufgebe, wollte ich eine Baseline, und die Zahlen sind sich nicht einig.

  • 3x Mellanox ConnectX-5 EN, MCX516A-CCAT, Dual-Port QSFP28
  • ein 100G-DAC zwischen jedem Knotenpaar
  • AMD-EPYC-Hosts, Proxmox auf allen drei

ethtool ist völlig zufrieden:

# ethtool ens1
Settings for ens1:
        Supported link modes:   100000baseCR4/Full
        Advertised link modes:  100000baseCR4/Full
        Speed: 100000Mb/s
        Duplex: Full
        Link detected: yes

lshw nicht:

# lshw -class network
  *-network
       description: Ethernet interface
       vendor: Mellanox Technologies
       capacity: 40Gbit/s

Und iperf3 zwischen zwei der Knoten pendelt sich bei etwa 21 Gbit/s ein, was zu keiner der beiden Zahlen auch nur in die Nähe kommt.

Bereits gemacht:

  • das Kabel auf beiden Karten in den zweiten Port gesteckt, keine Änderung
  • ein anderes DAC desselben Typs eingesetzt, keine Änderung
  • der Link bleibt die ganze Zeit up, keine steigenden Fehler in den Zählern

Welches der beiden Tools lügt mich also an, und sollte ich hinter dem Kabel, der Karte oder dem Treiber her sein?

Show original (English) Also available in: English العربية Deutsch Español Français हिन्दी Bahasa Indonesia Italiano 日本語 한국어 Nederlands Polski Português Русский Türkçe Tiếng Việt 简体中文
connectx-5 DAC iperf pcie QSFP28
United Kingdom coaxpilot98 GB

Comments 5

Accepted answer

Nichts von dem, was du gepostet hast, zeigt auf das DAC. Hier passieren zwei Dinge, die nichts miteinander zu tun haben.

Erstens die Widersprüchlichkeit. lshw -class network gibt eine Capability-Zahl aus, die es sich selbst zusammenrechnet, und bei diesen Karten sagt es munter capacity: 40Gbit/s zu einem Link, der mit 100G hochgekommen ist. Die ausgehandelte Rate steht in dem, was ethtool meldet, und bei dir steht dort Speed: 100000Mb/s mit 100000baseCR4/Full als Advertised. Diese Seite ist in Ordnung, da gibt es nichts zu reparieren.

Zweitens der Durchsatz. Erst den Slot prüfen, bevor sonst irgendwas angefasst wird:

# lspci -vv
        LnkCap: ... Speed 8GT/s ...
        LnkSta: ... Speed 2.5GT/s ... (downgraded)

Trainiert LnkSta bei 2.5GT/s, während LnkCap 8GT/s sagt, ist die Karte weit unter der Leitung gedeckelt, und kein noch so großer Kabeltausch wird daran etwas ändern. Karte neu setzen und sicherstellen, dass sie in einem Slot sitzt, der wirklich für die volle Breite verdrahtet ist.

Dann aufhören, mit einem einzigen Stream zu messen:

# iperf3 -P 8 -c <peer>

Rund 21 Gbit/s ist etwa das, was ein einzelner Core auf dieser Host-Klasse hergibt, diese Zahl allein sagt also sehr wenig aus. Während des Laufs die CPU beobachten und auch schauen, was die Idle-States treiben: Cores, die zwischen den Bursts in tiefe C-States fallen, kosten bei dieser Rate echte Bandbreite.

3 Taiwanlinkeng56TW Show original (English) AI translation

Bevor irgendein Ersatzteil bestellt wird: die LnkSta-Zeile aus lspci -vv für diese Karte posten und die genaue iperf3-Kommandozeile, die benutzt wurde. Ein Stream bei 100G misst einen einzelnen CPU-Core, nicht den Link, und Leute verbrennen Tage damit. Und bestätigen, dass der zweite Port beim Test wirklich das andere Bein des Mesh trägt und nicht untätig herumsitzt: Ein Slot, der zwei lebende 100G-Ports füttert, hat ein anderes Budget als einer. lshw würde ich vorerst beiseitelegen, das ist nicht das richtige Werkzeug für diese Frage.

3 United Arab Emirateslambdahawk88AE Show original (English) AI translation

Eine Korrektur zum C-State-Teil: Wenn die Hosts EPYC sind, bringen die intel_idle-Regler, die in jeden dieser Threads eingefügt werden, gar nichts, dieser Treiber liegt auf AMD überhaupt nicht im Pfad. Der Hebel, der bei mir funktioniert hat, war processor.max_cstate=2 auf der Kernel-Kommandozeile. Gleiche Idee, andere Plattform. Der Rest des Posts steht, insbesondere keine ausgehandelte Rate aus lshw abzulesen.

2 SpainoptictechES Show original (English) AI translation

Ein etwas anderer Fehler, gleiche Hardwarefamilie, lohnt sich auszuschließen, sobald der Slot geklärt ist: Ein direktes Mesh aus ConnectX-5-QSFP28-Ports lässt sich auf Layer 3 sehr leicht falsch aufsetzen. Ich hatte drei Knoten auf MCX516A-CCA_Ax, Firmware 16.35.4030 mit dem DOCA-2.8.0-Treiber, verkabelt mit MCP1600-C003E30L 3-m-Kupfer-DAC. Jeder Link meldete sich als aktiv mit 100 Gbps, und kein einziger Ping kam durch. Alle sechs Mesh-Interfaces hatten Adressen aus demselben Subnetz 10.5.5.x, ohne dass irgendwo im Pfad ein Switch war, der Kernel hatte also keine Möglichkeit zu entscheiden, zu welchem physischen Port ein bestimmtes Ziel gehörte. Ein Subnetz pro Knotenpaar, 10.5.5.x, 10.5.6.x und 10.5.7.x, und es fing an zu funktionieren. Lohnt sich, ip a und ip route auf allen drei Boxen laufen zu lassen, bevor jemand dem Kupfer die Schuld gibt.

1 Ukrainerxnode71UA Show original (English) AI translation

Beide Punkte haben gesessen. lspci -vv zeigte die Karte bei 2.5GT/s trainiert gegen ein LnkCap von 8GT/s, das war also Verdächtiger Nummer eins. Ich habe die Karten in allen drei Boxen in andere Slots gesteckt, LnkSta kommt jetzt bei 8GT/s hoch, und mit iperf3 -P 8 ging dasselbe Knotenpaar sofort über den Einzel-Stream-Wert hinaus.

Ich habe außerdem den Broadcast-Bond aufgegeben und das Mesh auf Open vSwitch mit RSTP neu aufgebaut. Mit iperf verteilt über drei CPU-Threads und beide Ports messe ich jetzt etwa 95 Gbit/s, was für das, was dieser Cluster macht, nah genug an der Leitungsrate ist. lshw besteht weiterhin auf 40Gbit/s, und ich habe aufgehört, dort hinzuschauen.

1 United Kingdomcoaxpilot98GB Show original (English) AI translation
Log in to comment. Log in