MikroTik CRS812 400G-breakout naar DGX Spark: 200G-link plafonneert op 106 Gb/s en NCCL valt terug op Socket
We zetten vier DGX Spark-nodes op voor distributed training en hingen ze aan een MikroTik CRS812-8DS-2DQ-2DDQ. Het plan was één 400G QSFP-DD-poort op de switch die twee nodes voedt met elk 200G, zodat een paar breakout-kabels de hele cluster dekken.
- MikroTik CRS812-8DS-2DQ-2DDQ, QSFP-DD-poorten gebruikt in breakout-modus
- NADDOD Q2Q56-400G-CU2, QSFP-DD 400G naar 2x QSFP56 200G passieve DAC
- DGX Spark-nodes met onboard ConnectX-7
- validatie met iperf3 en nccl-tests all_reduce_perf
Beide kanten melden een schone 200GbE-link, maar de doorvoer blijft steken op iets meer dan de helft daarvan:
# 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 ziet er nog slechter uit: all_reduce_perf meldt Socket transport en ruwweg 2 GB/s busbandbreedte over de vier nodes, dus RDMA wordt duidelijk helemaal niet gebruikt.
Wat we al gecontroleerd hebben:
- de breakout-kabel opnieuw geplaatst en verwisseld tussen switchpoorten, identieke cijfers
- het aantal streams verhoogd, het totaal blijft vastgepind rond 106 Gb/s
- bevestigd dat de switch de poort als 200G meldt, niet als 100G
Waar ik steeds op terugkom: één fysieke QSFP56-poort verschijnt als twee logische interfaces op de node. Levert de breakout maar de helft van de lanes aan elke node, of hoort een 200G-poort er op deze hardware gewoon zo uit te zien?
Comments 7
Dat is precies wat het is, en de breakout-kabel is onschuldig. Op dit platform is de ConnectX-7-poort aangesloten via PCIe x4 en wordt hij blootgesteld als twee logische helften, elk goed voor ongeveer 100 Gb/s. De volle 200G verschijnt alleen wanneer beide helften tegelijk belast worden, dus een iperf3-run met één adres die net over 100 Gb/s stopt is het verwachte resultaat en geen storing.
Wat het hier liet werken:
Met beide helften die verkeer dragen zou je dicht bij line rate op het paar moeten uitkomen, en nccl-tests all_reduce_perf zal een compleet andere klasse busbandbreedte melden zodra het niet meer via sockets loopt.
Voordat je de kabel de schuld geeft: hoe stuur je die twee interfaces precies aan? Je plakte enp1s0f1np1 en enP2p1s0f1np1 als allebei UP, maar raakt iperf3 ze allebei, of alleen die ene die een adres draagt?
Ook de moeite van het posten waard: de MTU op de nodes en op de CRS812-poorten, want 1500 doet flink pijn op dit tempo, en de inhoud van /etc/nccl.conf. Wanneer NCCL voor Socket transport kiest, komt dat vrijwel altijd doordat iets in dat bestand het vertelde het IB-pad niet aan te raken, niet doordat de fabric kapot is.
Terechte vragen. Alleen enp1s0f1np1 heeft een adres, de helft enP2p1s0f1np1 is up maar ongeconfigureerd, en elke iperf3-run tot nu toe ging naar dat ene adres. MTU is 1500 op de nodes en ik heb ook de L2-MTU aan de switchkant niet aangeraakt. En ja, daar is het:
Dat zat al in de image en ik heb het nooit in twijfel getrokken. Dus die 106 Gb/s is mogelijk gewoon één helft van de poort plus een beetje speelruimte?
Andere stack, zelfde vorm van verrassing. Mijn kant was een ConnectX-6 (MT28908) onder RHEL 8.4, MLNX_OFED 5.7, firmware 20.32.2004, MFT 4.21; het verre uiteinde een Switch-IB 2 SB7800, en daartussen een LinkX MCP7H50-H002R26-splitter die 200G terugbracht naar 2x100G. De poort kwam op als
en noch mlxlink -d mlx5_0 -p 1 --speeds edr noch --speeds hdr veranderde iets. Bleek een plafond in het silicium te zijn, geen configuratiefout: EDR-apparatuur vormt links alleen 1x of 4x breed, en een splitter van dat type leunt op 2x-groepering, die met HDR arriveerde. Dus óf een gewone 4x EDR-kabel in die switch, óf overstappen naar HDR als de split een must is.
Moraal voor breakouts in het algemeen: zoek uit welke lane-groepering elk uiteinde daadwerkelijk kan vormen voordat je ook maar iets meet.
Eén ding uit het recept hierboven verdient het om uitgespeld te worden, want daar verliezen mensen de winst weer: de MTU moet ook op de switch kloppen. 9000 instellen op de hosts terwijl de poorten nog steeds frames van 1500 byte doorlaten, levert je drops op in plaats van doorvoer. Zet de L2-MTU op de CRS812-poorten en verifieer met een ping met grote payload voordat je een test opnieuw draait.
Het IPv6-punt is hetzelfde verhaal. Met beide helften geadresseerd en IPv6 aan, krijg je extra GID-items per poort, en de index die je test kreeg opgedragen te gebruiken is niet per se degene die je denkt. IPv6 uitzetten op de CX7-interfaces houdt die tabel klein en voorspelbaar over reboots heen, wat meer uitmaakt dan het klinkt wanneer je runs vergelijkt.
De moeite waard om te onthouden: een breakout-poort die down blijft is een compleet ander beest dan die van jou. Op een tweedehands Arista DCS-7060CX-32S (EOS 4.16.8FX-7060X) toonden mijn vier subinterfaces helemaal geen fouten en linkten ze gewoon nooit. De box stond op transceiver qsfp default-mode 4x10G terwijl het verre uiteinde 25G aanbood, en Et17/1 bleef errdisabled tot de snelheid met de hand werd ingesteld:
In diezelfde sessie werd een Mellanox-kabel geweigerd als niet-gekwalificeerde transceiver en moest vervangen worden door een Arista-compatibele 100GBASE-CR4 QSFP28-DAC. Aan het andere uiterste kreeg een collega nooit een QDD-4X100G-2P5M-breakout omhoog op een QFX5220-32CD met Junos 23.2R1-S1.8-EVO richting een Mellanox-switch, met een portprofiel dat de Port Checker had goedgekeurd en elke FEC-variant geprobeerd. Die van jou onderhandelt en verwerkt tenminste verkeer.
Bevestigd, en de poort is nooit kapot geweest. Ik heb enP2p1s0f1np1 als eigen interface geadresseerd, MTU 9000 gezet op de nodes en op de switchpoorten, IPv6 uitgezet op beide CX7-interfaces en NCCL_IB_DISABLE=1 verwijderd uit /etc/nccl.conf.
Twee parallelle iperf3-sessies, één per helft, geven nu 196-198 Gb/s in totaal. all_reduce_perf over de vier nodes meldt 23,76 GB/s busbandbreedte en NCCL zit op het RDMA-pad, geen Socket transport meer in het log. De NADDOD Q2Q56-400G-CU2 had de hele tijd al zijn werk gedaan.