Mesh de MCX516A-CCAT em DAC 100G: o lshw diz 40Gbit/s e um stream de iperf3 estagna em 21 Gbit/s
A gente roda um cluster de três nós com os nós cabeados direto um no outro por DAC 100G, sem switch no caminho, e as interfaces colocadas num bond broadcast para o tráfego de replicação ter a própria fabric. Antes de colocar carga de verdade nisso eu queria uma linha de base, e os números não batem entre si.
- 3x Mellanox ConnectX-5 EN, MCX516A-CCAT, porta dupla QSFP28
- um DAC 100G entre cada par de nós
- hosts AMD EPYC, Proxmox nos três
O ethtool está perfeitamente feliz:
# ethtool ens1
Settings for ens1:
Supported link modes: 100000baseCR4/Full
Advertised link modes: 100000baseCR4/Full
Speed: 100000Mb/s
Duplex: Full
Link detected: yesO lshw não está:
# lshw -class network
*-network
description: Ethernet interface
vendor: Mellanox Technologies
capacity: 40Gbit/sE o iperf3 entre dois dos nós fica em uns 21 Gbit/s, o que não chega perto de nenhuma das duas marcas.
Já feito:
- movi o cabo para a segunda porta nas duas placas, sem mudança
- troquei por outro DAC do mesmo tipo, sem mudança
- o link fica up o tempo todo, nenhum erro subindo nos contadores
Então qual das duas ferramentas está mentindo para mim, e é o cabo, a placa ou o driver que eu deveria investigar?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
Nada do que você postou aponta para o DAC. Tem duas coisas sem relação acontecendo aqui.
Primeiro, a divergência. O
lshw -class networkimprime um número de capacidade que ele calcula por conta própria, e nessas placas ele vai alegremente dizercapacity: 40Gbit/ssobre um link que subiu a 100G. A taxa negociada é o que oethtoolreporta, e o seu dizSpeed: 100000Mb/scom100000baseCR4/Fullanunciado. Esse lado está bom, não tem nada para consertar.Segundo, o throughput. Confira o slot antes de mexer em mais nada:
Se o
LnkStatreinou em 2.5GT/s enquanto oLnkCapdiz 8GT/s, você está limitado bem abaixo do fio e nenhuma troca de cabo vai ajudar. Reencaixe a placa e garanta que ela está num slot que realmente está cabeado para a largura completa.Depois pare de medir com um stream só:
Uns 21 Gbit/s é mais ou menos o que um núcleo sozinho te dá nessa classe de host, então esse número sozinho diz muito pouco. Observe a CPU durante o teste e veja também o que os idle states estão fazendo: núcleos caindo em C-states profundos entre rajadas custam banda real nessa taxa.
Antes de pedir a substituição de qualquer coisa, posta a linha
LnkStadolspci -vvpara essa placa e a linha de comando exata do iperf3 que você usou. Um stream a 100G mede um único núcleo de CPU, não o link, e as pessoas queimam dias nisso. E confirme que a segunda porta está realmente carregando a outra perna do mesh enquanto você testa, em vez de ficar ociosa: um slot alimentando duas portas 100G ao vivo é um orçamento diferente de um só. Eu deixaria olshwde lado por enquanto, não é a ferramenta certa para essa pergunta.Uma correção na parte dos C-states: se os hosts são EPYC, os knobs de
intel_idleque aparecem colados em toda essa thread não fazem nada para você, esse driver nem entra no caminho em AMD. A alavanca que funcionou para mim foiprocessor.max_cstate=2na linha de comando do kernel. Mesma ideia, plataforma diferente. O resto daquele post continua valendo, em particular não ler a taxa negociada nolshw.Falha um pouco diferente, mesma família de hardware, vale descartar assim que o slot estiver resolvido: um mesh direto de portas ConnectX-5 QSFP28 é muito fácil de errar na camada 3. Eu tinha três nós num MCX516A-CCA_Ax, firmware 16.35.4030 com o driver DOCA 2.8.0, cabeados com DAC de cobre MCP1600-C003E30L de 3 m. Todo link reportava ativo a 100 Gbps e nenhum ping atravessava. As seis interfaces do mesh tinham endereços de uma única sub-rede 10.5.5.x sem switch nenhum no caminho, então o kernel não tinha como decidir a qual porta física um determinado destino pertencia. Uma sub-rede por par de nós, 10.5.5.x, 10.5.6.x e 10.5.7.x, e começou a funcionar. Vale rodar
ip aeip routenas três caixas antes de alguém culpar o cobre.Os dois pontos bateram. O
lspci -vvmostrou a placa treinada em 2.5GT/s contra umLnkCapde 8GT/s, então esse foi o suspeito número um. Movi as placas para outros slots nas três caixas, oLnkStaagora sobe em 8GT/s, e comiperf3 -P 8o mesmo par de nós imediatamente passou do número de stream único.Também desisti do bond broadcast e reconstruí o mesh em Open vSwitch com RSTP. Com o iperf espalhado em três threads de CPU e as duas portas, estou medindo uns 95 Gbit/s agora, que é perto o bastante da taxa de linha para o que esse cluster faz. O
lshwainda insiste em 40Gbit/s e eu parei de olhar para ele.