CodingBox Q&A Ask question
Log in Sign up

MCX516A-CCAT mesh over 100G DAC: lshw zegt 40Gbit/s en één iperf3-stream haalt maximaal 21 Gbit/s

Asked Active Viewed 49 AI translation from English
2

We draaien een cluster van drie nodes waarbij de nodes rechtstreeks op elkaar bekabeld zijn via 100G DAC, geen switch in het pad, en de interfaces zitten in een broadcast bond zodat replicatieverkeer zijn eigen fabric heeft. Voor ik er echte belasting op zette wilde ik een baseline, en de cijfers zijn het niet met elkaar eens.

  • 3x Mellanox ConnectX-5 EN, MCX516A-CCAT, dual-port QSFP28
  • één 100G DAC tussen elk paar nodes
  • AMD EPYC-hosts, Proxmox op alle drie

ethtool is helemaal tevreden:

# ethtool ens1
Settings for ens1:
        Supported link modes:   100000baseCR4/Full
        Advertised link modes:  100000baseCR4/Full
        Speed: 100000Mb/s
        Duplex: Full
        Link detected: yes

lshw niet:

# lshw -class network
  *-network
       description: Ethernet interface
       vendor: Mellanox Technologies
       capacity: 40Gbit/s

En iperf3 tussen twee van de nodes zit op ruwweg 21 Gbit/s, wat bij geen van beide cijfers in de buurt komt.

Al gedaan:

  • de kabel naar de tweede poort op beide kaarten verplaatst, geen verandering
  • een andere DAC van hetzelfde type geprobeerd, geen verandering
  • link blijft de hele tijd up, geen oplopende fouten op de counters

Welke van de twee tools liegt er dus tegen me, en moet ik achter de kabel, de kaart of de driver aan?

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 简体中文
connectx-5 DAC iperf pcie QSFP28
United Kingdom coaxpilot98 GB

Comments 5

Accepted answer

Niets van wat je gepost hebt wijst naar de DAC. Er spelen hier twee losstaande dingen.

Eerst, de tegenspraak. lshw -class network print een capaciteitscijfer dat het zelf uitrekent, en op deze kaarten zegt het vrolijk capacity: 40Gbit/s over een link die op 100G is opgekomen. De onderhandelde snelheid is wat ethtool meldt, en bij jou staat er Speed: 100000Mb/s met 100000baseCR4/Full geadverteerd. Dat deel is in orde, daar valt niets aan te repareren.

Ten tweede, de doorvoer. Controleer de slot voor je iets anders aanraakt:

# lspci -vv
        LnkCap: ... Speed 8GT/s ...
        LnkSta: ... Speed 2.5GT/s ... (downgraded)

Traint LnkSta op 2,5GT/s terwijl LnkCap 8GT/s zegt, dan zit je ruim onder de kabelcapaciteit en helpt geen enkele kabelwissel. Zet de kaart opnieuw in de slot en zorg dat hij in een slot zit dat echt op volle breedte bedraad is.

Stop dan met meten via één enkele stream:

# iperf3 -P 8 -c <peer>

Rond de 21 Gbit/s is ongeveer wat één core je geeft op dit soort host, dus dat cijfer alleen zegt je heel weinig. Houd de CPU in de gaten tijdens de run en kijk ook wat de idle states doen: cores die tussen bursts in diepe C-states wegzakken kosten je bij deze snelheid echte bandbreedte.

3 Taiwanlinkeng56TW Show original (English) AI translation

Voor je iets ter vervanging bestelt, post de LnkSta-regel uit lspci -vv voor die kaart en de exacte iperf3-commandoregel die je gebruikt hebt. Eén stream op 100G meet één CPU-core, niet de link, en mensen verbranden hier dagen aan. En bevestig dat de tweede poort tijdens het testen echt de andere tak van de mesh draagt, in plaats van stil te zitten: één slot dat twee live 100G-poorten voedt is een ander budget dan één. Ik zou lshw voorlopig laten rusten, dat is niet het gereedschap voor deze vraag.

3 United Arab Emirateslambdahawk88AE Show original (English) AI translation

Eén correctie op het C-state-deel: als de hosts EPYC zijn, doen de intel_idle-knoppen die in elk van deze threads worden geplakt helemaal niets voor je, die driver zit bij AMD gewoon niet in het pad. De hendel die bij mij werkte was processor.max_cstate=2 op de kernel command line. Zelfde idee, ander platform. De rest van die post klopt nog steeds, in het bijzonder: geen onderhandelde snelheid uit lshw aflezen.

2 SpainoptictechES Show original (English) AI translation

Iets ander falen, zelfde familie hardware, de moeite waard om uit te sluiten zodra de slot in orde is: een directe mesh van ConnectX-5 QSFP28-poorten gaat op laag 3 heel makkelijk fout. Ik had drie nodes op de MCX516A-CCA_Ax, firmware 16.35.4030 met de DOCA 2.8.0-driver, bekabeld met MCP1600-C003E30L koperen DAC van 3 m. Elke link meldde zich actief op 100 Gbps en geen enkele ping kwam erdoorheen. Alle zes mesh-interfaces hadden adressen uit één en hetzelfde 10.5.5.x-subnet zonder switch waar dan ook in het pad, dus de kernel had geen manier om te bepalen bij welke fysieke poort een bepaalde bestemming hoorde. Eén subnet per nodepaar, 10.5.5.x, 10.5.6.x en 10.5.7.x, en toen ging het werken. De moeite waard om ip a en ip route op alle drie de dozen te draaien voor iemand koper de schuld geeft.

1 Ukrainerxnode71UA Show original (English) AI translation

Beide punten klopten. lspci -vv liet zien dat de kaart trainde op 2,5GT/s tegenover een LnkCap van 8GT/s, dus dat was verdachte nummer één. Ik heb de kaarten naar andere sloten op alle drie de dozen verplaatst, LnkSta komt nu op 8GT/s, en met iperf3 -P 8 ging hetzelfde nodepaar meteen voorbij het single-stream-cijfer.

Ik heb ook de broadcast bond losgelaten en de mesh herbouwd op Open vSwitch met RSTP. Met iperf verspreid over drie CPU-threads en beide poorten meet ik nu zo'n 95 Gbit/s, wat dicht genoeg bij line rate zit voor wat dit cluster doet. lshw houdt nog steeds vol dat het 40Gbit/s is en ik ben ermee gestopt ernaar te kijken.

1 United Kingdomcoaxpilot98GB Show original (English) AI translation
Log in to comment. Log in