MikroTik CRS812 400G-Breakout zu DGX Spark: 200G-Link deckelt bei 106 Gb/s, NCCL fällt auf Socket zurück
Wir bauen vier DGX-Spark-Knoten für verteiltes Training auf und hängen sie an einen MikroTik CRS812-8DS-2DQ-2DDQ. Der Plan war ein 400G-QSFP-DD-Port am Switch, der zwei Knoten mit je 200G versorgt, sodass ein paar Breakout-Kabel den ganzen Cluster abdecken.
- MikroTik CRS812-8DS-2DQ-2DDQ, QSFP-DD-Ports im Breakout-Modus verwendet
- NADDOD Q2Q56-400G-CU2, passives DAC QSFP-DD 400G auf 2x QSFP56 200G
- DGX-Spark-Knoten mit onboard ConnectX-7
- Validierung mit iperf3 und nccl-tests all_reduce_perf
Beide Enden melden einen sauberen 200GbE-Link, aber der Durchsatz liegt bei etwas über der Hälfte davon:
# iperf3 -c <peer> -P 8
[SUM] 0.00-10.00 sec ... 106 Gbits/sec
single stream: ~30 Gbits/sec
# ip -br link
enp1s0f1np1 UP
enP2p1s0f1np1 UPNCCL sieht noch schlechter aus: all_reduce_perf meldet Socket transport und rund 2 GB/s Busbandbreite über die vier Knoten hinweg, RDMA wird also eindeutig überhaupt nicht genutzt.
Was wir schon geprüft haben:
- das Breakout-Kabel neu eingesetzt und zwischen Switch-Ports getauscht, identische Zahlen
- die Stream-Zahl erhöht, das Aggregat bleibt nahe 106 Gb/s festgenagelt
- bestätigt, dass der Switch den Port mit 200G meldet, nicht 100G
Worauf ich immer wieder zurückkomme: Ein physischer QSFP56-Port zeigt sich am Knoten als zwei logische Interfaces. Liefert der Breakout jedem Knoten nur die halben Lanes, oder soll ein 200G-Port auf dieser Hardware genau so aussehen?
Comments 7
Genau das ist es, und das Breakout-Kabel ist unschuldig. Auf dieser Plattform hängt der ConnectX-7-Port über PCIe x4 und wird als zwei logische Hälften exponiert, jede mit rund 100 Gb/s. Die vollen 200G zeigen sich nur, wenn beide Hälften gleichzeitig ausgelastet sind, ein iperf3-Lauf mit einer einzigen Adresse, der knapp über 100 Gb/s stehen bleibt, ist also das erwartete Ergebnis und kein Fehler.
Was es hier zum Laufen gebracht hat:
Wenn beide Hälften Traffic tragen, solltet ihr nahe an die Leitungsrate des Paars herankommen, und nccl-tests all_reduce_perf meldet eine völlig andere Klasse von Busbandbreite, sobald es nicht mehr über Sockets läuft.
Bevor dem Kabel die Schuld gegeben wird: Wie genau werden diese beiden Interfaces angesteuert? Ihr habt enp1s0f1np1 und enP2p1s0f1np1 als beide UP gepostet, aber trifft iperf3 auf beide, oder nur auf das, welches gerade eine Adresse trägt?
Auch interessant zu posten: die MTU auf den Knoten und auf den CRS812-Ports, denn 1500 tut bei dieser Rate richtig weh, und der Inhalt von /etc/nccl.conf. Wenn NCCL Socket transport wählt, liegt es fast immer daran, dass etwas in dieser Datei ihm gesagt hat, den IB-Pfad nicht anzufassen, nicht daran, dass die Fabric kaputt ist.
Faire Fragen. Nur enp1s0f1np1 hat eine Adresse, die Hälfte enP2p1s0f1np1 ist up, aber unkonfiguriert, und jeder iperf3-Lauf bisher ging an diese eine Adresse. MTU ist 1500 auf den Knoten, und die L2-MTU auf der Switch-Seite habe ich auch nicht angefasst. Und ja, da ist es:
Das war schon im Image, und ich habe es nie infrage gestellt. Sind die 106 Gb/s also möglicherweise nur eine Hälfte des Ports plus etwas Spielraum?
Anderer Stack, gleiche Art von Überraschung. Bei mir war es ein ConnectX-6 (MT28908) unter RHEL 8.4, MLNX_OFED 5.7, Firmware 20.32.2004, MFT 4.21; am anderen Ende ein Switch-IB 2 SB7800, dazwischen ein LinkX-MCP7H50-H002R26-Splitter, der 200G auf 2x100G herunterbricht. Der Port kam hoch als
und weder mlxlink -d mlx5_0 -p 1 --speeds edr noch --speeds hdr haben etwas geändert. Stellte sich als Deckel im Silizium heraus statt als Konfigurationsfehler: EDR-Geräte bilden Links nur 1x oder 4x breit, und ein Splitter dieser Art setzt auf 2x-Gruppierung, die erst mit HDR kam. Also entweder ein reines 4x-EDR-Kabel in diesen Switch, oder auf HDR wechseln, wenn der Split sein muss.
Moral für Breakouts allgemein: erst herausfinden, welche Lane-Gruppierung jedes Ende tatsächlich bilden kann, bevor irgendwas gemessen wird.
Eine Sache aus dem Rezept oben verdient es, ausbuchstabiert zu werden, weil genau dort die Gewinne wieder verlorengehen: Die MTU muss auch am Switch passen. 9000 auf den Hosts zu setzen, während die Ports noch 1500-Byte-Frames durchlassen, bringt Drops statt Durchsatz. Die L2-MTU auf den CRS812-Ports setzen und mit einem Ping mit großer Payload verifizieren, bevor irgendein Test wiederholt wird.
Der IPv6-Punkt ist dieselbe Geschichte. Mit beiden adressierten Hälften und eingeschaltetem IPv6 bekommt man zusätzliche GID-Einträge pro Port, und der Index, den der Test benutzen soll, ist nicht zwangsläufig der, den man denkt. IPv6 auf den CX7-Interfaces abzuschalten hält diese Tabelle klein und über Reboots hinweg vorhersagbar, was mehr zählt, als es klingt, wenn man Läufe vergleicht.
Im Kopf behalten, dass ein Breakout-Port, der down bleibt, ein ganz anderes Tier ist als eurer. An einem gebrauchten Arista DCS-7060CX-32S (EOS 4.16.8FX-7060X) zeigten meine vier Sub-Interfaces überhaupt keine Fehler und linkten einfach nie. Die Box stand bei transceiver qsfp default-mode 4x10G, während die Gegenseite 25G präsentierte, und Et17/1 blieb errdisabled, bis die Rate von Hand gesetzt wurde:
In derselben Sitzung wurde ein Mellanox-Kabel als nicht qualifizierter Transceiver abgelehnt und musste gegen ein Arista-kompatibles 100GBASE-CR4-QSFP28-DAC getauscht werden. Am anderen Extrem hat ein Kollege nie einen QDD-4X100G-2P5M-Breakout auf einem QFX5220-32CD mit Junos 23.2R1-S1.8-EVO in Richtung eines Mellanox-Switches hochbekommen, mit einem Port-Profil, das der Port Checker validiert hatte, und jeder FEC-Variante, die probiert wurde. Eurer verhandelt wenigstens und lässt Traffic durch.
Bestätigt, und der Port war nie kaputt. Ich habe enP2p1s0f1np1 als eigenes Interface adressiert, MTU 9000 auf den Knoten und den Switch-Ports gesetzt, IPv6 auf beiden CX7-Interfaces abgeschaltet und NCCL_IB_DISABLE=1 aus /etc/nccl.conf entfernt.
Zwei parallele iperf3-Sitzungen, eine pro Hälfte, ergeben jetzt 196-198 Gb/s im Aggregat. all_reduce_perf meldet über die vier Knoten hinweg 23.76 GB/s Busbandbreite, und NCCL läuft auf dem RDMA-Pfad, kein Socket transport mehr im Log. Das NADDOD Q2Q56-400G-CU2 hat die ganze Zeit seinen Job gemacht.