CodingBox Q&A Ask question
Log in Sign up

Maillage MCX516A-CCAT sur DAC 100G : lshw annonce 40 Gbit/s et un seul flux iperf3 plafonne à 21 Gbit/s

Asked Active Viewed 49 AI translation from English
2

Nous faisons tourner un cluster de trois nœuds câblés directement entre eux en DAC 100G, aucun switch dans le chemin, et les interfaces sont montées en bond broadcast pour que le trafic de réplication ait son propre tissu. Avant de mettre une vraie charge dessus je voulais une base de référence, et les chiffres ne s'accordent pas entre eux.

  • 3x Mellanox ConnectX-5 EN, MCX516A-CCAT, double port QSFP28
  • un DAC 100G entre chaque paire de nœuds
  • hôtes AMD EPYC, Proxmox sur les trois

ethtool est parfaitement content :

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

lshw ne l'est pas :

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

Et iperf3 entre deux des nœuds se stabilise autour de 21 Gbit/s, ce qui n'est proche d'aucun des deux chiffres.

Déjà fait :

  • déplacé le câble vers le second port sur les deux cartes, aucun changement
  • remplacé par un autre DAC du même type, aucun changement
  • le lien reste up tout du long, aucune erreur qui grimpe sur les compteurs

Alors lequel des deux outils me ment, et est-ce le câble, la carte ou le driver que je devrais viser ?

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

Rien de ce que vous avez posté ne pointe vers le DAC. Il y a deux choses sans rapport qui se passent ici.

D'abord, le désaccord. lshw -class network affiche un chiffre de capacité qu'il calcule tout seul, et sur ces cartes il dira allègrement capacity: 40Gbit/s à propos d'un lien monté à 100G. Le débit négocié, c'est ethtool qui le rapporte, et le vôtre indique Speed: 100000Mb/s avec 100000baseCR4/Full annoncé. Cette partie-là est correcte, il n'y a rien à corriger.

Ensuite, le débit réel. Vérifiez le slot avant de toucher à autre chose :

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

Si LnkSta s'est entraîné à 2.5GT/s alors que LnkCap annonce 8GT/s, vous êtes plafonné bien en dessous du câble et aucun échange de câble n'y changera rien. Réinsérez la carte et assurez-vous qu'elle est dans un slot réellement câblé à la pleine largeur.

Ensuite arrêtez de mesurer avec un seul flux :

# iperf3 -P 8 -c <peer>

Environ 21 Gbit/s, c'est à peu près ce qu'un seul cœur vous donnera sur cette classe d'hôte, donc ce chiffre seul vous dit très peu de choses. Surveillez le CPU pendant le test et regardez aussi ce que font les états d'inactivité : des cœurs qui tombent dans des C-states profonds entre les rafales vous coûtent de la vraie bande passante à ce débit.

3 Taiwanlinkeng56TW Show original (English) AI translation

Avant de commander quoi que ce soit en remplacement, postez la ligne LnkSta de lspci -vv pour cette carte et la ligne de commande iperf3 exacte que vous avez utilisée. Un seul flux à 100G mesure un seul cœur CPU, pas le lien, et les gens perdent des jours là-dessus. Et confirmez que le second port porte vraiment l'autre branche du maillage pendant votre test, plutôt que de rester inactif : un slot alimentant deux ports 100G actifs, c'est un budget différent d'un seul. Je mettrais lshw de côté pour l'instant, ce n'est pas l'outil pour cette question.

3 United Arab Emirateslambdahawk88AE Show original (English) AI translation

Une correction sur la partie C-states : si les hôtes sont EPYC, les réglages intel_idle qu'on colle dans chacun de ces fils ne vous servent à rien, ce driver n'est même pas dans le chemin sur AMD. Le levier qui a fonctionné pour moi était processor.max_cstate=2 sur la ligne de commande du noyau. Même idée, plateforme différente. Le reste de ce message tient, en particulier le fait de ne pas lire un débit négocié dans lshw.

2 SpainoptictechES Show original (English) AI translation

Panne légèrement différente, même famille de matériel, ça vaut la peine de l'écarter une fois le slot réglé : un maillage direct de ports ConnectX-5 QSFP28 est très facile à mal configurer en couche 3. J'avais trois nœuds en MCX516A-CCA_Ax, firmware 16.35.4030 avec le driver DOCA 2.8.0, câblés avec des DAC cuivre MCP1600-C003E30L de 3 m. Chaque lien s'affichait actif à 100 Gbit/s et pas un seul ping ne passait. Les six interfaces du maillage avaient toutes des adresses issues d'un seul sous-réseau 10.5.5.x sans aucun switch dans le chemin, donc le noyau n'avait aucun moyen de décider à quel port physique appartenait une destination donnée. Un sous-réseau par paire de nœuds, 10.5.5.x, 10.5.6.x et 10.5.7.x, et ça s'est mis à fonctionner. Ça vaut la peine de lancer ip a et ip route sur les trois boîtiers avant que quelqu'un accuse le cuivre.

1 Ukrainerxnode71UA Show original (English) AI translation

Les deux points ont fait mouche. lspci -vv montrait la carte entraînée à 2.5GT/s contre un LnkCap de 8GT/s, donc c'était le suspect numéro un. J'ai déplacé les cartes vers d'autres slots sur les trois boîtiers, LnkSta monte maintenant à 8GT/s, et avec iperf3 -P 8 la même paire de nœuds a immédiatement dépassé le chiffre à flux unique.

J'ai aussi abandonné le bond broadcast et reconstruit le maillage sur Open vSwitch avec RSTP. Avec iperf réparti sur trois threads CPU et les deux ports, je mesure maintenant environ 95 Gbit/s, ce qui est assez proche du débit de ligne pour ce que fait ce cluster. lshw continue d'affirmer 40Gbit/s et j'ai arrêté de le regarder.

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