Breakout de 400G en MikroTik CRS812 hacia DGX Spark: el enlace de 200G se limita a 106 Gb/s y NCCL cae a Socket
Estamos montando cuatro nodos DGX Spark para entrenamiento distribuido y los colgamos de una MikroTik CRS812-8DS-2DQ-2DDQ. El plan era que un puerto QSFP-DD de 400G en el switch alimentara a dos nodos a 200G cada uno, así que un par de cables breakout cubren todo el clúster.
- MikroTik CRS812-8DS-2DQ-2DDQ, puertos QSFP-DD usados en modo breakout
- NADDOD Q2Q56-400G-CU2, DAC pasivo QSFP-DD 400G a 2x QSFP56 200G
- Nodos DGX Spark con ConnectX-7 integrado
- validación con iperf3 y nccl-tests all_reduce_perf
Ambos extremos reportan un enlace limpio de 200GbE, pero el throughput queda en algo más de la mitad de eso:
# 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 se ve todavía peor: all_reduce_perf reporta transporte Socket y aproximadamente 2 GB/s de ancho de banda de bus a través de los cuatro nodos, así que claramente RDMA no se está usando en absoluto.
Lo que ya hemos revisado:
- reasentamos y cambiamos el cable breakout entre puertos del switch, números idénticos
- subimos el número de streams, el agregado se queda fijo cerca de 106 Gb/s
- confirmamos que el switch reporta el puerto a 200G, no a 100G
La parte a la que sigo volviendo es que un puerto físico QSFP56 aparece como dos interfaces lógicas en el nodo. ¿El breakout solo está entregando la mitad de los carriles a cada nodo, o un puerto de 200G en este hardware se supone que se ve así?
Comments 7
Eso es exactamente lo que es, y el cable breakout es inocente. En esta plataforma el puerto de la ConnectX-7 está conectado por PCIe x4 y se expone como dos mitades lógicas, cada una con unos 100 Gb/s. Los 200G completos solo aparecen cuando ambas mitades están cargadas al mismo tiempo, así que una corrida de iperf3 con una sola dirección deteniéndose justo pasado los 100 Gb/s es el resultado esperado y no un fallo.
Lo que funcionó aquí:
Con ambas mitades llevando tráfico deberías acercarte a la tasa de línea en el par, y nccl-tests all_reduce_perf reportará una clase completamente distinta de ancho de banda de bus en cuanto deje de pasar por sockets.
Antes de culpar al cable, ¿cómo exactamente estás manejando esas dos interfaces? Pegaste enp1s0f1np1 y enP2p1s0f1np1 como ambas UP, pero ¿iperf3 les llega a las dos, o solo a la que tiene una dirección?
También vale la pena publicar: la MTU en los nodos y en los puertos de la CRS812, porque 1500 duele mucho a esta tasa, y el contenido de /etc/nccl.conf. Cuando NCCL elige el transporte Socket es casi siempre porque algo en ese archivo le dijo que no tocara la ruta IB, no porque el fabric esté roto.
Buenas preguntas. Solo enp1s0f1np1 tiene dirección, la mitad enP2p1s0f1np1 está arriba pero sin configurar, y todas las corridas de iperf3 hasta ahora fueron a esa única dirección. La MTU es 1500 en los nodos y tampoco he tocado la MTU L2 del lado del switch. Y sí, ahí está:
Eso ya venía en la imagen y nunca lo cuestioné. Entonces, ¿los 106 Gb/s son posiblemente solo una mitad del puerto más un poco de margen?
Pila distinta, mismo tipo de sorpresa. Mi caso era una ConnectX-6 (MT28908) bajo RHEL 8.4, MLNX_OFED 5.7, firmware 20.32.2004, MFT 4.21; el otro extremo un Switch-IB 2 SB7800, y entre los dos un splitter LinkX MCP7H50-H002R26 bajando de 200G a 2x100G. El puerto subió como
y ni mlxlink -d mlx5_0 -p 1 --speeds edr ni --speeds hdr cambiaron nada. Resultó ser un techo en el silicio y no un error de configuración: el equipo EDR solo forma enlaces de 1x o 4x de ancho, y un splitter de ese tipo se apoya en la agrupación 2x, que llegó con HDR. Así que o un cable EDR de 4x normal hacia ese switch, o pasar a HDR si el split es imprescindible.
Moraleja para los breakout en general: averigua qué agrupación de carriles puede formar realmente cada extremo antes de medir nada.
Una cosa de la receta de arriba merece decirse explícitamente, porque es donde la gente vuelve a perder las ganancias: la MTU también tiene que coincidir en el switch. Poner 9000 en los hosts mientras los puertos siguen pasando tramas de 1500 bytes te compra descartes en vez de throughput. Fija la MTU L2 en los puertos de la CRS812 y verifica con un ping de payload grande antes de volver a correr cualquier prueba.
El punto de IPv6 es la misma historia. Con ambas mitades direccionadas y IPv6 dejado activo obtienes entradas GID extra por puerto, y el índice que tu prueba usa no es necesariamente el que crees. Apagar IPv6 en las interfaces CX7 mantiene esa tabla pequeña y predecible entre reinicios, lo cual importa más de lo que parece cuando estás comparando corridas.
Vale la pena tener en cuenta que un puerto breakout que se queda caído es un animal completamente distinto al tuyo. En una Arista DCS-7060CX-32S de segunda mano (EOS 4.16.8FX-7060X) mis cuatro subinterfaces no mostraban ningún error y simplemente nunca enlazaron. La caja estaba en transceiver qsfp default-mode 4x10G mientras el otro extremo presentaba 25G, y Et17/1 se quedó en errdisabled hasta que se fijó la tasa a mano:
En la misma sesión, un cable Mellanox fue rechazado como transceptor no cualificado y hubo que cambiarlo por un DAC QSFP28 100GBASE-CR4 compatible con Arista. En el otro extremo, un colega nunca consiguió levantar un breakout QDD-4X100G-2P5M en una QFX5220-32CD corriendo Junos 23.2R1-S1.8-EVO hacia un switch Mellanox, con un perfil de puerto que el Port Checker validaba y probando cada variante de FEC. El tuyo al menos negocia y pasa tráfico.
Confirmado, y el puerto nunca estuvo roto. Le di dirección a enP2p1s0f1np1 como su propia interfaz, puse MTU 9000 en los nodos y en los puertos del switch, apagué IPv6 en ambas interfaces CX7 y quité NCCL_IB_DISABLE=1 de /etc/nccl.conf.
Dos sesiones de iperf3 en paralelo, una por cada mitad, ahora dan 196-198 Gb/s de agregado. all_reduce_perf a través de los cuatro nodos reporta 23.76 GB/s de ancho de banda de bus y NCCL está en la ruta RDMA, ya no hay transporte Socket en el log. El NADDOD Q2Q56-400G-CU2 había estado haciendo su trabajo todo el tiempo.