Mesh di MCX516A-CCAT su DAC 100G: lshw dice 40Gbit/s e un singolo stream iperf3 arriva al massimo a 21 Gbit/s
Gestiamo un cluster a tre nodi con i nodi cablati direttamente l'uno all'altro su DAC 100G, nessuno switch nel percorso, e le interfacce messe in un bond broadcast così il traffico di replica ha la sua fabric dedicata. Prima di metterci sopra un carico vero volevo una baseline, e i numeri non sono d'accordo tra loro.
- 3x Mellanox ConnectX-5 EN, MCX516A-CCAT, dual-port QSFP28
- un DAC 100G tra ogni coppia di nodi
- host AMD EPYC, Proxmox su tutti e tre
ethtool è perfettamente soddisfatto:
# ethtool ens1
Settings for ens1:
Supported link modes: 100000baseCR4/Full
Advertised link modes: 100000baseCR4/Full
Speed: 100000Mb/s
Duplex: Full
Link detected: yeslshw no:
# lshw -class network
*-network
description: Ethernet interface
vendor: Mellanox Technologies
capacity: 40Gbit/sE iperf3 tra due dei nodi sta a circa 21 Gbit/s, che non è vicino a nessuna delle due cifre.
Già fatto:
- spostato il cavo sulla seconda porta su entrambe le schede, nessun cambiamento
- scambiato con un altro DAC dello stesso tipo, nessun cambiamento
- il link resta su tutto il tempo, nessun errore che sale sui contatori
Quindi quale dei due strumenti mi sta mentendo, e devo dare la colpa al cavo, alla scheda o al driver?
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
Niente di quello che hai postato punta al DAC. Ci sono due cose scorrelate che succedono qui.
Prima cosa, il disaccordo.
lshw -class networkstampa una cifra di capacità che calcola per conto suo, e su queste schede dirà allegramentecapacity: 40Gbit/sa proposito di un link che è salito a 100G. La velocità negoziata è quella che riportaethtool, e la tua diceSpeed: 100000Mb/scon100000baseCR4/Fullannunciato. Quel lato è a posto, non c'è niente da correggere.Seconda cosa, il throughput. Controlla lo slot prima di toccare altro:
Se
LnkStasi è allenato a 2.5GT/s mentreLnkCapdice 8GT/s, sei limitato ben al di sotto del filo e nessuna quantità di cavi cambiati aiuterà. Reinserisci la scheda e assicurati che stia in uno slot davvero cablato per la larghezza piena.Poi smetti di misurare con un singolo stream:
Circa 21 Gbit/s è più o meno quello che un solo core ti darà su questa classe di host, quindi quel numero da solo ti dice ben poco. Guarda la CPU durante il run e guarda anche cosa fanno gli idle state: i core che scendono in C-state profondi tra un burst e l'altro ti costano banda reale a questa velocità.
Prima di ordinare qualsiasi ricambio, posta la riga
LnkStadalspci -vvper quella scheda e la riga di comando iperf3 esatta che hai usato. Un singolo stream a 100G misura un solo core CPU, non il link, e la gente ci brucia giorni sopra. E conferma che la seconda porta stia davvero portando l'altra gamba della mesh mentre testi, invece di stare ferma inattiva: uno slot che alimenta due porte 100G attive è un budget diverso da uno solo. Per ora metterei da partelshw, non è lo strumento giusto per questa domanda.Una correzione sulla parte dei C-state: se gli host sono EPYC, le manopole
intel_idleche vengono incollate in ognuno di questi thread non ti servono a niente, quel driver non è affatto nel percorso su AMD. La leva che ha funzionato per me è stataprocessor.max_cstate=2sulla command line del kernel. Stessa idea, piattaforma diversa. Il resto di quel post resta valido, in particolare non leggere una velocità negoziata dalshw.Guasto leggermente diverso, stessa famiglia di hardware, vale la pena escluderlo una volta sistemato lo slot: una mesh diretta di porte ConnectX-5 QSFP28 è facilissima da sbagliare al layer 3. Avevo tre nodi su MCX516A-CCA_Ax, firmware 16.35.4030 con il driver DOCA 2.8.0, cablati con DAC in rame MCP1600-C003E30L da 3 m. Ogni link riportava attivo a 100 Gbps e non passava un ping. Tutte e sei le interfacce mesh avevano indirizzi da un'unica subnet 10.5.5.x senza nessuno switch da nessuna parte nel percorso, quindi il kernel non aveva modo di decidere a quale porta fisica appartenesse una data destinazione. Una subnet per coppia di nodi, 10.5.5.x, 10.5.6.x e 10.5.7.x, e ha iniziato a funzionare. Vale la pena lanciare
ip aeip routesu tutte e tre le scatole prima che qualcuno dia la colpa al rame.Entrambi i punti sono andati a segno.
lspci -vvmostrava la scheda allenata a 2.5GT/s contro unLnkCapdi 8GT/s, quindi quello era il sospettato numero uno. Ho spostato le schede in altri slot su tutte e tre le scatole,LnkStaora sale a 8GT/s, e coniperf3 -P 8la stessa coppia di nodi è andata subito oltre la cifra a singolo stream.Ho anche rinunciato al bond broadcast e ricostruito la mesh su Open vSwitch con RSTP. Con iperf distribuito su tre thread CPU ed entrambe le porte sto misurando circa 95 Gbit/s adesso, abbastanza vicino alla line rate per quello che fa questo cluster.
lshwinsiste ancora su 40Gbit/s e ho smesso di guardarlo.