CodingBox Q&A Ask question
Log in Sign up

Меш MCX516A-CCAT на 100G DAC: lshw пишет 40Gbit/s, а один поток iperf3 упирается в 21 Гбит/с

Asked Active Viewed 49 AI translation from English
2

У нас трёхнодовый кластер, узлы соединены напрямую друг с другом по 100G DAC, без коммутатора в тракте, интерфейсы объединены в broadcast-бонд, чтобы трафик репликации имел свою собственную фабрику. Прежде чем давать реальную нагрузку, я хотел получить базовые цифры, и они не сходятся друг с другом.

  • 3x Mellanox ConnectX-5 EN, MCX516A-CCAT, два порта QSFP28
  • по одному 100G DAC между каждой парой узлов
  • хосты AMD EPYC, Proxmox на всех трёх

ethtool вполне доволен:

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

lshw - нет:

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

А iperf3 между двумя узлами держится на уровне примерно 21 Гбит/с, что не похоже ни на одну из двух цифр.

Уже сделано:

  • переставил кабель на второй порт обеих карт - без изменений
  • поменял на другой DAC того же типа - без изменений
  • линк держится всё время, ошибки по счётчикам не растут

Так какой из двух инструментов мне врёт, и за что браться - за кабель, карту или драйвер?

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

Ничто из того, что вы выложили, не указывает на DAC. Здесь происходят две не связанные друг с другом вещи.

Первое - расхождение. lshw -class network печатает показатель ёмкости, который вычисляет сам, и на этих картах он вполне спокойно напишет capacity: 40Gbit/s про линк, поднявшийся на 100G. Согласованную скорость показывает ethtool, а у вас там Speed: 100000Mb/s с заявленным 100000baseCR4/Full. Эта сторона в порядке, чинить тут нечего.

Второе - пропускная способность. Прежде чем трогать что-то ещё, проверьте слот:

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

Если LnkSta согласовался на 2.5GT/s при LnkCap в 8GT/s, вы упёрлись в потолок далеко ниже провода, и никакая смена кабелей не поможет. Переустановите карту и убедитесь, что она сидит в слоте, реально разведённом на полную ширину.

Затем перестаньте измерять одним потоком:

# iperf3 -P 8 -c <peer>

Около 21 Гбит/с - это примерно то, что даст одно ядро на хосте такого класса, так что само по себе это число почти ничего не говорит. Следите за загрузкой CPU во время прогона и посмотрите, что делают состояния простоя: ядра, уходящие в глубокие C-states между всплесками, реально отъедают полосу на такой скорости.

3 Taiwanlinkeng56TW Show original (English) AI translation

Прежде чем заказывать замену чему-либо, выложите строку LnkSta из lspci -vv для этой карты и точную команду iperf3, которую использовали. Один поток на 100G измеряет одно ядро CPU, а не линк, и на этом люди теряют дни. И подтвердите, что второй порт реально несёт другое плечо меша во время теста, а не простаивает: один слот, питающий два живых порта 100G, - это совсем другой бюджет по сравнению с одним. Я бы пока отложил lshw, это не тот инструмент для этого вопроса.

3 United Arab Emirateslambdahawk88AE Show original (English) AI translation

Одна поправка насчёт C-states: если хосты на EPYC, ручки intel_idle, которые копируют во все подобные темы, вам ничем не помогут, этот драйвер вообще не задействован на AMD. Рычаг, который сработал у меня - processor.max_cstate=2 в командной строке ядра. Та же идея, другая платформа. Остальное в том сообщении верно, в частности насчёт того, что не стоит читать согласованную скорость из lshw.

2 SpainoptictechES Show original (English) AI translation

Немного другая неисправность, то же семейство железа, стоит исключить, как только слот приведён в порядок: прямой меш из портов ConnectX-5 QSFP28 очень легко испортить на уровне 3. У меня было три узла на MCX516A-CCA_Ax, прошивка 16.35.4030 с драйвером DOCA 2.8.0, соединены медным DAC MCP1600-C003E30L на 3 м. Каждый линк сообщал active на 100 Гбит/с, и ни один пинг не проходил. Все шесть интерфейсов меша имели адреса из одной и той же подсети 10.5.5.x без коммутатора где-либо в тракте, так что у ядра не было способа решить, к какому физическому порту относится данный адрес назначения. По одной подсети на пару узлов, 10.5.5.x, 10.5.6.x и 10.5.7.x, и всё заработало. Стоит прогнать ip a и ip route на всех трёх коробках, прежде чем кто-то обвинит медь.

1 Ukrainerxnode71UA Show original (English) AI translation

Оба момента попали в цель. lspci -vv показал, что карта согласовалась на 2.5GT/s против LnkCap в 8GT/s, так что это был подозреваемый номер один. Переставил карты в другие слоты на всех трёх коробках, LnkSta теперь поднимается на 8GT/s, и с iperf3 -P 8 та же пара узлов сразу превысила однопотоковую цифру.

Я также отказался от broadcast-бонда и пересобрал меш на Open vSwitch с RSTP. При iperf, распределённом по трём потокам CPU и обоим портам, я теперь измеряю около 95 Гбит/с, что достаточно близко к линейной скорости для того, чем занимается этот кластер. lshw всё ещё настаивает на 40Gbit/s, и я перестал на него смотреть.

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