Breakout 400G del MikroTik CRS812 verso DGX Spark: il link 200G si ferma a 106 Gb/s e NCCL torna a Socket
Stiamo mettendo in piedi quattro nodi DGX Spark per il training distribuito e li abbiamo appesi a un MikroTik CRS812-8DS-2DQ-2DDQ. Il piano era una porta 400G QSFP-DD sullo switch che alimenta due nodi a 200G ciascuno, così un paio di cavi breakout coprono tutto il cluster.
- MikroTik CRS812-8DS-2DQ-2DDQ, porte QSFP-DD usate in modalità breakout
- NADDOD Q2Q56-400G-CU2, DAC passivo QSFP-DD 400G verso 2x QSFP56 200G
- nodi DGX Spark con ConnectX-7 integrato
- validazione con iperf3 e nccl-tests all_reduce_perf
Entrambi i capi riportano un link 200GbE pulito, ma il throughput sta un po' sopra la metà di quello:
# 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 sembra peggio ancora: all_reduce_perf riporta trasporto Socket e circa 2 GB/s di bus bandwidth sui quattro nodi, quindi l'RDMA chiaramente non viene usato per niente.
Cosa abbiamo già controllato:
- reinserito e scambiato il cavo breakout tra le porte dello switch, numeri identici
- alzato il numero di stream, l'aggregato resta inchiodato vicino a 106 Gb/s
- confermato che lo switch riporta la porta a 200G, non 100G
La parte su cui continuo a tornare è che una porta fisica QSFP56 appare come due interfacce logiche sul nodo. Il breakout sta consegnando solo metà delle lane a ciascun nodo, o una porta 200G su questo hardware deve apparire così per natura?
Comments 7
È esattamente quello, e il cavo breakout è innocente. Su questa piattaforma la porta ConnectX-7 è collegata via PCIe x4 e viene esposta come due metà logiche, ciascuna che porta circa 100 Gb/s. I 200G pieni si vedono solo quando entrambe le metà sono caricate contemporaneamente, quindi un run iperf3 su un solo indirizzo che si ferma appena sopra i 100 Gb/s è il risultato atteso, non un guasto.
Quello che ha funzionato qui:
Con entrambe le metà che portano traffico dovresti arrivare vicino al line rate sulla coppia, e nccl-tests all_reduce_perf riporterà una classe completamente diversa di bus bandwidth una volta che smette di passare per i socket.
Prima di dare la colpa al cavo, come stai esattamente pilotando quelle due interfacce? Hai incollato enp1s0f1np1 ed enP2p1s0f1np1 entrambe UP, ma iperf3 colpisce entrambe, o solo quella che porta un indirizzo?
Vale la pena postare anche: l'MTU sui nodi e sulle porte del CRS812, perché 1500 fa male parecchio a questo rate, e il contenuto di /etc/nccl.conf. Quando NCCL sceglie il trasporto Socket è quasi sempre perché qualcosa in quel file gli ha detto di non toccare il percorso IB, non perché la fabric sia rotta.
Domande giuste. Solo enp1s0f1np1 ha un indirizzo, la metà enP2p1s0f1np1 è up ma non configurata, e ogni run iperf3 finora è andato verso quel singolo indirizzo. L'MTU è 1500 sui nodi e non ho toccato l'MTU L2 nemmeno lato switch. E sì, eccolo lì:
Era già nell'immagine e non l'ho mai messo in discussione. Quindi i 106 Gb/s sono forse solo una metà della porta più un po' di margine?
Stack diverso, stesso tipo di sorpresa. Dal mio lato c'era un ConnectX-6 (MT28908) sotto RHEL 8.4, MLNX_OFED 5.7, firmware 20.32.2004, MFT 4.21; all'altro capo uno Switch-IB 2 SB7800, e tra i due uno splitter LinkX MCP7H50-H002R26 che portava 200G giù a 2x100G. La porta saliva come
e né mlxlink -d mlx5_0 -p 1 --speeds edr né --speeds hdr cambiavano niente. È risultato essere un tetto nel silicio piuttosto che un errore di configurazione: l'hardware EDR forma link larghi solo 1x o 4x, e uno splitter di quel tipo si appoggia al raggruppamento 2x, arrivato con l'HDR. Quindi o un cavo EDR 4x semplice in quello switch, oppure passare a HDR se lo split è un obbligo.
Morale per i breakout in generale: capisci che raggruppamento di lane ciascun capo può davvero formare prima di misurare qualsiasi cosa.
Una cosa della ricetta sopra merita di essere spiegata per esteso, perché è dove la gente riperde di nuovo i guadagni: l'MTU deve corrispondere anche sullo switch. Impostare 9000 sugli host mentre le porte passano ancora frame da 1500 byte ti compra drop invece che throughput. Imposta l'MTU L2 sulle porte del CRS812 e verifica con un ping a payload grande prima di rifare qualsiasi test.
Il discorso IPv6 è la stessa storia. Con entrambe le metà indirizzate e IPv6 lasciato attivo ottieni voci GID extra per porta, e l'indice che al tuo test è stato detto di usare non è necessariamente quello che pensi. Spegnere IPv6 sulle interfacce CX7 tiene quella tabella piccola e prevedibile tra un reboot e l'altro, il che conta più di quanto sembri quando confronti i run.
Vale la pena tenere presente che una porta breakout che resta down è un animale completamente diverso dal tuo. Su un Arista DCS-7060CX-32S (EOS 4.16.8FX-7060X) di seconda mano le mie quattro sotto-interfacce non mostravano nessun errore e semplicemente non facevano mai link. La scatola stava su transceiver qsfp default-mode 4x10G mentre l'altro capo presentava 25G, ed Et17/1 restava errdisabled finché il rate non veniva impostato a mano:
Nella stessa sessione un cavo Mellanox è stato rifiutato come transceiver non qualificato e ha dovuto essere sostituito con un DAC QSFP28 100GBASE-CR4 compatibile Arista. All'altro estremo, un collega non è mai riuscito a far salire un breakout QDD-4X100G-2P5M su un QFX5220-32CD con Junos 23.2R1-S1.8-EVO verso uno switch Mellanox, con un port profile validato dal Port Checker e ogni variante FEC provata. Il tuo almeno negozia e passa traffico.
Confermato, e la porta non era mai stata rotta. Ho indirizzato enP2p1s0f1np1 come sua propria interfaccia, impostato MTU 9000 sui nodi e sulle porte dello switch, spento IPv6 su entrambe le interfacce CX7 e rimosso NCCL_IB_DISABLE=1 da /etc/nccl.conf.
Due sessioni iperf3 parallele, una per metà, ora danno 196-198 Gb/s aggregati. all_reduce_perf sui quattro nodi riporta 23,76 GB/s di bus bandwidth e NCCL è sul percorso RDMA, nessun trasporto Socket nel log ormai. Il NADDOD Q2Q56-400G-CU2 aveva fatto il suo lavoro per tutto il tempo.