CodingBox Q&A Ask question
Log in Sign up

Mesh MCX516A-CCAT na 100G DAC: lshw pokazuje 40Gbit/s, a jeden strumień iperf3 dobija najwyżej do 21 Gbit/s

Asked Active Viewed 49 AI translation from English
2

Prowadzimy trzywęzłowy klaster, węzły połączone bezpośrednio kablami po 100G DAC, bez switcha po drodze, a interfejsy wpięte w broadcast bond, żeby ruch replikacji miał własną fabrykę. Zanim dałem na to realny ruch, chciałem punkt odniesienia, a liczby nie zgadzają się ze sobą.

  • 3x Mellanox ConnectX-5 EN, MCX516A-CCAT, dual-port QSFP28
  • jeden 100G DAC między każdą parą węzłów
  • hosty AMD EPYC, Proxmox na wszystkich trzech

ethtool jest w pełni zadowolony:

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

lshw nie jest:

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

A iperf3 między dwoma węzłami siedzi na jakichś 21 Gbit/s, co nie jest bliskie żadnej z tych liczb.

Już zrobione:

  • przełożyłem kabel na drugi port na obu kartach, bez zmian
  • podmieniłem na inny DAC tego samego typu, bez zmian
  • link stoi cały czas, żadnych rosnących błędów na licznikach

Więc które z tych dwóch narzędzi mnie okłamuje, i czy to kabel, karta czy driver, za którym powinienem gonić?

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

Nic z tego, co napisałeś, nie wskazuje na DAC. Dzieją się tu dwie niezależne rzeczy.

Pierwsza, rozbieżność. lshw -class network drukuje własną wyliczoną liczbę możliwości i przy tych kartach spokojnie powie capacity: 40Gbit/s o linku, który wstał na 100G. Wynegocjowaną prędkość zgłasza ethtool, a u ciebie stoi Speed: 100000Mb/s z advertised 100000baseCR4/Full. Ta strona sprawy jest w porządku, nie ma czego naprawiać.

Druga, przepustowość. Zanim ruszysz cokolwiek innego, sprawdź slot:

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

Jeśli LnkSta wytrenował na 2.5GT/s, podczas gdy LnkCap mówi 8GT/s, jesteś ucięty daleko poniżej możliwości łącza i żadna podmiana kabli tu nie pomoże. Wyjmij i osadź kartę ponownie, i upewnij się, że siedzi w slocie faktycznie okablowanym na pełną szerokość.

Potem przestań mierzyć jednym strumieniem:

# iperf3 -P 8 -c <peer>

Około 21 Gbit/s to mniej więcej tyle, ile da ci jeden rdzeń na tej klasie hosta, więc ta liczba sama w sobie mówi bardzo niewiele. Obserwuj CPU podczas testu i zerknij też, co robią stany bezczynności: rdzenie schodzące w głębokie C-state między seriami kosztują cię realne pasmo przy tej prędkości.

3 Taiwanlinkeng56TW Show original (English) AI translation

Zanim zamówisz cokolwiek na wymianę, wklej linię LnkSta z lspci -vv dla tej karty i dokładną linię komend iperf3, której użyłeś. Jeden strumień na 100G mierzy pojedynczy rdzeń CPU, nie link, i ludzie palą na tym dni. I potwierdź, że drugi port faktycznie niesie drugą nogę mesha podczas testu, a nie stoi bezczynnie: jeden slot karmiący dwa żywe porty 100G to inny budżet niż jeden. Na razie odłożyłbym lshw na bok, to nie jest narzędzie do tego pytania.

3 United Arab Emirateslambdahawk88AE Show original (English) AI translation

Jedna poprawka co do C-state: jeśli hosty to EPYC, przełączniki intel_idle wklejane w każdym z takich wątków nic ci nie dają, ten driver w ogóle nie jest w grze na AMD. Dźwignia, która zadziałała u mnie, to processor.max_cstate=2 w linii poleceń jądra. Ten sam pomysł, inna platforma. Reszta tamtego posta się broni, w szczególności to, żeby nie czytać wynegocjowanej prędkości z lshw.

2 SpainoptictechES Show original (English) AI translation

Nieco inna awaria, ta sama rodzina sprzętu, warto wykluczyć, jak już slot jest ogarnięty: bezpośredni mesh portów ConnectX-5 QSFP28 bardzo łatwo popsuć na warstwie 3. Miałem trzy węzły na MCX516A-CCA_Ax, firmware 16.35.4030 ze sterownikiem DOCA 2.8.0, okablowane MCP1600-C003E30L 3 m copper DAC. Każdy link zgłaszał się jako aktywny na 100 Gbps i ani jeden ping nie przeszedł. Wszystkie sześć interfejsów mesha miało adresy z jednej podsieci 10.5.5.x, bez żadnego switcha po drodze, więc jądro nie miało jak zdecydować, do którego fizycznego portu należy dany cel. Jedna podsieć na parę węzłów, 10.5.5.x, 10.5.6.x i 10.5.7.x, i zaczęło działać. Warto odpalić ip a i ip route na wszystkich trzech maszynach, zanim ktoś obwini miedź.

1 Ukrainerxnode71UA Show original (English) AI translation

Obie rzeczy się potwierdziły. lspci -vv pokazało, że karta wytrenowała na 2.5GT/s wobec LnkCap równego 8GT/s, więc to był podejrzany numer jeden. Przełożyłem karty do innych slotów na wszystkich trzech maszynach, LnkSta teraz wstaje na 8GT/s, i z iperf3 -P 8 ta sama para węzłów od razu przeskoczyła wynik z pojedynczego strumienia.

Odpuściłem też broadcast bond i przebudowałem mesh na Open vSwitch z RSTP. Z iperf rozłożonym na trzy wątki CPU i oba porty mierzę teraz około 95 Gbit/s, co jest wystarczająco blisko line rate jak na potrzeby tego klastra. lshw dalej upiera się przy 40Gbit/s i przestałem na to patrzeć.

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