Breakout 400G MikroTik CRS812 vers DGX Spark : le lien 200G plafonne à 106 Gb/s et NCCL retombe en Socket
On met en place quatre nœuds DGX Spark pour l'entraînement distribué et on les a accrochés à un MikroTik CRS812-8DS-2DQ-2DDQ. Le plan était un port QSFP-DD 400G sur le switch alimentant deux nœuds à 200G chacun, de sorte qu'une paire de câbles de breakout couvre tout le cluster.
- MikroTik CRS812-8DS-2DQ-2DDQ, ports QSFP-DD utilisés en mode breakout
- NADDOD Q2Q56-400G-CU2, DAC passif QSFP-DD 400G vers 2x QSFP56 200G
- Nœuds DGX Spark avec ConnectX-7 intégré
- validation avec iperf3 et nccl-tests all_reduce_perf
Les deux bouts signalent un lien 200GbE propre, mais le débit se situe un peu au-dessus de la moitié de ça :
# 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 a l'air pire que ça : all_reduce_perf rapporte un transport Socket et environ 2 GB/s de bande passante bus sur les quatre nœuds, donc le RDMA n'est clairement pas utilisé du tout.
Ce qu'on a déjà vérifié :
- réinséré et échangé le câble de breakout entre les ports du switch, chiffres identiques
- augmenté le nombre de flux, l'agrégat reste bloqué près de 106 Gb/s
- confirmé que le switch rapporte le port en 200G, pas en 100G
Ce sur quoi je reviens sans cesse, c'est qu'un port physique QSFP56 apparaît comme deux interfaces logiques sur le nœud. Est-ce que le breakout ne délivre que la moitié des voies à chaque nœud, ou un port 200G sur ce matériel est-il censé se présenter comme ça ?
Comments 7
C'est exactement ça, et le câble de breakout est innocent. Sur cette plateforme, le port ConnectX-7 est rattaché via PCIe x4 et exposé comme deux moitiés logiques, chacune portant environ 100 Gb/s. Le 200G complet n'apparaît que lorsque les deux moitiés sont chargées en même temps, donc un run iperf3 sur une seule adresse s'arrêtant juste après 100 Gb/s est le résultat attendu plutôt qu'un défaut.
Ce qui a fait fonctionner ça ici :
Avec les deux moitiés portant du trafic, vous devriez atterrir près du débit ligne sur la paire, et nccl-tests all_reduce_perf rapportera une classe de bande passante bus complètement différente une fois qu'il arrête de passer par les sockets.
Avant d'accuser le câble, comment pilotez-vous exactement ces deux interfaces ? Vous avez collé enp1s0f1np1 et enP2p1s0f1np1 toutes les deux comme UP, mais est-ce qu'iperf3 les touche toutes les deux, ou seulement celle qui porte une adresse ?
Utile à poster aussi : le MTU sur les nœuds et sur les ports du CRS812, parce que 1500 fait vraiment mal à ce débit, et le contenu de /etc/nccl.conf. Quand NCCL choisit le transport Socket, c'est presque toujours parce que quelque chose dans ce fichier lui a dit de ne pas toucher au chemin IB, pas parce que le fabric est cassé.
Bonnes questions. Seule enp1s0f1np1 a une adresse, la moitié enP2p1s0f1np1 est up mais non configurée, et tous les runs iperf3 jusqu'ici sont allés vers cette seule adresse. Le MTU est à 1500 sur les nœuds et je n'ai pas touché non plus au MTU L2 côté switch. Et oui, le voilà :
C'était déjà dans l'image et je ne l'ai jamais remis en question. Donc les 106 Gb/s sont peut-être juste une moitié du port plus un peu de marge ?
Pile différente, même genre de surprise. Mon côté était un ConnectX-6 (MT28908) sous RHEL 8.4, MLNX_OFED 5.7, firmware 20.32.2004, MFT 4.21 ; l'autre bout un Switch-IB 2 SB7800, et entre les deux un splitter LinkX MCP7H50-H002R26 ramenant le 200G à 2x100G. Le port est monté en
et ni mlxlink -d mlx5_0 -p 1 --speeds edr ni --speeds hdr n'ont rien changé. Il s'est avéré que c'était un plafond dans le silicium plutôt qu'une erreur de config : le matériel EDR ne forme des liens que sur 1x ou 4x voies de large, et un splitter de ce type s'appuie sur un groupement 2x, arrivé avec le HDR. Donc soit un simple câble EDR 4x vers ce switch, soit passer en HDR si le split est indispensable.
Morale pour les breakouts en général : déterminez quel groupement de voies chaque bout peut réellement former avant de mesurer quoi que ce soit.
Un point de la recette ci-dessus mérite d'être précisé, parce que c'est là que les gens reperdent les gains : le MTU doit aussi correspondre sur le switch. Régler 9000 sur les hôtes pendant que les ports laissent encore passer des trames de 1500 octets vous achète des pertes plutôt que du débit. Réglez le MTU L2 sur les ports du CRS812 et vérifiez avec un ping à grande charge utile avant de relancer un quelconque test.
Le point sur IPv6 raconte la même histoire. Avec les deux moitiés adressées et IPv6 laissé activé, vous obtenez des entrées GID supplémentaires par port, et l'index que votre test a été chargé d'utiliser n'est pas nécessairement celui que vous croyez. Désactiver IPv6 sur les interfaces CX7 garde cette table petite et prévisible entre redémarrages, ce qui compte plus qu'il n'y paraît quand vous comparez des runs.
Bon à garder en tête qu'un port de breakout qui reste down est une bête complètement différente de la vôtre. Sur un Arista DCS-7060CX-32S d'occasion (EOS 4.16.8FX-7060X), mes quatre sous-interfaces ne montraient aucune erreur du tout et n'ont simplement jamais monté. Le boîtier était sur transceiver qsfp default-mode 4x10G alors que l'autre bout présentait du 25G, et Et17/1 restait errdisabled jusqu'à ce que le débit soit réglé à la main :
Dans la même session, un câble Mellanox a été refusé comme transceiver non qualifié et a dû être remplacé par un DAC QSFP28 100GBASE-CR4 compatible Arista. À l'autre extrême, un collègue n'a jamais réussi à faire monter un breakout QDD-4X100G-2P5M sur un QFX5220-32CD tournant sous Junos 23.2R1-S1.8-EVO vers un switch Mellanox, avec un profil de port validé par le Port Checker et toutes les variantes de FEC essayées. Le vôtre au moins négocie et fait passer du trafic.
Confirmé, et le port n'a jamais été cassé. J'ai adressé enP2p1s0f1np1 comme sa propre interface, réglé MTU 9000 sur les nœuds et sur les ports du switch, désactivé IPv6 sur les deux interfaces CX7 et retiré NCCL_IB_DISABLE=1 de /etc/nccl.conf.
Deux sessions iperf3 parallèles, une par moitié, donnent maintenant 196-198 Gb/s d'agrégat. all_reduce_perf sur les quatre nœuds rapporte 23,76 GB/s de bande passante bus et NCCL est sur le chemin RDMA, plus de transport Socket dans le journal. Le NADDOD Q2Q56-400G-CU2 faisait son travail depuis le début.