Breakout 400G do MikroTik CRS812 para DGX Spark: link 200G trava em 106 Gb/s e o NCCL cai para Socket
Estamos montando quatro nós DGX Spark para treinamento distribuído e pendurando eles num MikroTik CRS812-8DS-2DQ-2DDQ. O plano era uma porta 400G QSFP-DD no switch alimentando dois nós a 200G cada, então alguns cabos breakout cobrem o cluster inteiro.
- MikroTik CRS812-8DS-2DQ-2DDQ, portas QSFP-DD usadas em modo breakout
- NADDOD Q2Q56-400G-CU2, DAC passivo QSFP-DD 400G para 2x QSFP56 200G
- nós DGX Spark com ConnectX-7 onboard
- validação com iperf3 e nccl-tests all_reduce_perf
As duas pontas reportam um link 200GbE limpo, mas o throughput fica um pouco acima da metade disso:
# 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 UPO NCCL parece pior que isso: o all_reduce_perf reporta Socket transport e mais ou menos 2 GB/s de bus bandwidth pelos quatro nós, então o RDMA claramente não está sendo usado.
O que já verificamos:
- reencaixamos e trocamos o cabo breakout entre portas do switch, números idênticos
- aumentamos a contagem de streams, o agregado continua preso perto de 106 Gb/s
- confirmamos que o switch reporta a porta em 200G, não 100G
A parte para a qual eu sempre volto é que uma porta física QSFP56 aparece como duas interfaces lógicas no nó. O breakout está entregando só metade dos lanes para cada nó, ou uma porta 200G nesse hardware deve mesmo parecer assim?
Comments 7
É exatamente isso, e o cabo breakout é inocente. Nessa plataforma a porta do ConnectX-7 é conectada via PCIe x4 e é exposta como duas metades lógicas, cada uma carregando cerca de 100 Gb/s. Os 200G completos só aparecem quando as duas metades estão carregadas ao mesmo tempo, então uma rodada de iperf3 com um único endereço parando logo depois de 100 Gb/s é o resultado esperado, não uma falha.
O que fez funcionar aqui:
Com as duas metades carregando tráfego, você deve chegar perto da taxa de linha no par, e o nccl-tests all_reduce_perf vai reportar uma classe completamente diferente de bus bandwidth assim que parar de passar por sockets.
Antes de culpar o cabo, como exatamente você está conduzindo essas duas interfaces? Você colou enp1s0f1np1 e enP2p1s0f1np1 como UP nas duas, mas o iperf3 está batendo nas duas, ou só naquela que carrega um endereço?
Também vale postar: o MTU nos nós e nas portas do CRS812, porque 1500 machuca muito nessa taxa, e o conteúdo de /etc/nccl.conf. Quando o NCCL escolhe Socket transport é quase sempre porque algo nesse arquivo disse para ele não tocar no caminho IB, não porque o fabric está quebrado.
Perguntas justas. Só a enp1s0f1np1 tem endereço, a metade enP2p1s0f1np1 está up mas não configurada, e toda rodada de iperf3 até agora foi para esse único endereço. O MTU está em 1500 nos nós e eu também não mexi no MTU L2 do lado do switch. E sim, aí está:
Isso já estava na imagem e eu nunca questionei. Então os 106 Gb/s são possivelmente só uma metade da porta mais uma pequena margem?
Pilha diferente, mesmo formato de surpresa. Do meu lado era um ConnectX-6 (MT28908) sob RHEL 8.4, MLNX_OFED 5.7, firmware 20.32.2004, MFT 4.21; na outra ponta um Switch-IB 2 SB7800, e entre os dois um splitter LinkX MCP7H50-H002R26 dividindo 200G em 2x100G. A porta subiu como
e nem mlxlink -d mlx5_0 -p 1 --speeds edr nem --speeds hdr mudaram alguma coisa. Acabou sendo um teto no próprio silício, não um erro de configuração: equipamento EDR só forma links de 1x ou 4x de largura, e um splitter desse tipo depende de agrupamento 2x, que só chegou com o HDR. Então ou um cabo EDR 4x simples nesse switch, ou migrar para HDR se o split for obrigatório.
Moral para breakouts em geral: descubra que agrupamento de lanes cada ponta realmente consegue formar antes de medir qualquer coisa.
Uma coisa da receita acima merece ser detalhada, porque é onde as pessoas perdem os ganhos de novo: o MTU precisa bater no switch também. Configurar 9000 nos hosts enquanto as portas ainda passam frames de 1500 bytes te compra descarte em vez de throughput. Configure o MTU L2 nas portas do CRS812 e confirme com um ping de payload grande antes de rodar qualquer teste de novo.
O ponto do IPv6 é a mesma história. Com as duas metades endereçadas e o IPv6 ligado, você ganha entradas GID extras por porta, e o índice que seu teste foi mandado usar não é necessariamente o que você pensa que é. Desligar o IPv6 nas interfaces CX7 mantém essa tabela pequena e previsível entre reboots, o que importa mais do que parece quando você está comparando rodadas.
Vale ter em mente que uma porta breakout que fica down é um animal completamente diferente do seu. Num Arista DCS-7060CX-32S (EOS 4.16.8FX-7060X) de segunda mão, minhas quatro sub-interfaces não mostravam erro nenhum e simplesmente nunca linkavam. A caixa estava em transceiver qsfp default-mode 4x10G enquanto a outra ponta apresentava 25G, e a Et17/1 ficava errdisabled até a taxa ser configurada manualmente:
Na mesma sessão, um cabo Mellanox foi recusado como transceptor não qualificado e teve que ser trocado por um DAC 100GBASE-CR4 QSFP28 compatível com Arista. No outro extremo, um colega nunca conseguiu subir um breakout QDD-4X100G-2P5M num QFX5220-32CD rodando Junos 23.2R1-S1.8-EVO em direção a um switch Mellanox, com um port profile que o Port Checker validou e cada variante de FEC testada. O seu pelo menos negocia e passa tráfego.
Confirmado, e a porta nunca esteve quebrada. Endereçei a enP2p1s0f1np1 como interface própria, configurei MTU 9000 nos nós e nas portas do switch, desliguei o IPv6 nas duas interfaces CX7 e removi o NCCL_IB_DISABLE=1 do /etc/nccl.conf.
Duas sessões de iperf3 em paralelo, uma por metade, agora dão 196-198 Gb/s agregados. O all_reduce_perf pelos quatro nós reporta 23.76 GB/s de bus bandwidth e o NCCL está no caminho RDMA, sem mais Socket transport no log. O NADDOD Q2Q56-400G-CU2 estava fazendo o trabalho dele o tempo todo.