Breakout 400G MikroTik CRS812 на DGX Spark: линк 200G упирается в 106 Гбит/с, а NCCL откатывается на Socket
Разворачиваем четыре узла DGX Spark для распределённого обучения и подключили их к MikroTik CRS812-8DS-2DQ-2DDQ. План был такой: один порт QSFP-DD 400G на коммутаторе питает два узла по 200G каждый, так что пара breakout-кабелей закрывает весь кластер.
- MikroTik CRS812-8DS-2DQ-2DDQ, порты QSFP-DD используются в режиме breakout
- NADDOD Q2Q56-400G-CU2, пассивный DAC QSFP-DD 400G в 2x QSFP56 200G
- узлы DGX Spark со встроенным ConnectX-7
- проверка через iperf3 и nccl-tests all_reduce_perf
Обе стороны сообщают о чистом линке 200GbE, но пропускная способность держится чуть выше половины от этого:
# iperf3 -c <peer> -P 8
[SUM] 0.00-10.00 sec ... 106 Gbits/sec
single stream: ~30 Gbits/sec
# ip -br link
enp1s0f1np1 UP
enP2p1s0f1np1 UPС NCCL всё выглядит ещё хуже: all_reduce_perf сообщает о транспорте Socket и примерно 2 ГБ/с пропускной способности шины по всем четырём узлам, то есть RDMA явно вообще не используется.
Что мы уже проверили:
- переустановили и поменяли местами breakout-кабель между портами коммутатора - цифры те же
- увеличили число потоков - суммарная скорость остаётся зафиксированной около 106 Гбит/с
- подтвердили, что коммутатор показывает порт на 200G, а не 100G
Больше всего меня смущает то, что один физический порт QSFP56 показывается как два логических интерфейса на узле. Breakout действительно отдаёт каждому узлу только половину линий, или порт 200G на этом железе так и должен выглядеть?
Comments 7
Именно так и есть, а breakout-кабель ни при чём. На этой платформе порт ConnectX-7 подключён по PCIe x4 и отображается как две логические половины, каждая из которых несёт около 100 Гбит/с. Полные 200G появляются только тогда, когда обе половины нагружены одновременно, так что однопоточный запуск iperf3, останавливающийся чуть выше 100 Гбит/с, - это ожидаемый результат, а не неисправность.
Что помогло здесь:
Когда обе половины несут трафик, вы должны выйти близко к линейной скорости на этой паре, а nccl-tests all_reduce_perf покажет совершенно другой класс пропускной способности шины, как только перестанет идти через сокеты.
Прежде чем винить кабель - как именно вы гоняете эти два интерфейса? Вы привели enp1s0f1np1 и enP2p1s0f1np1 как оба UP, но iperf3 бьёт по обоим, или только по тому, у которого есть адрес?
Стоит также привести: MTU на узлах и на портах CRS812, потому что 1500 сильно бьёт по такой скорости, и содержимое /etc/nccl.conf. Когда NCCL выбирает транспорт Socket, это почти всегда потому, что что-то в этом файле велело ему не трогать путь IB, а не потому, что фабрика сломана.
Справедливые вопросы. Адрес есть только у enp1s0f1np1, половина enP2p1s0f1np1 поднята, но не настроена, и все запуски iperf3 до сих пор шли на этот единственный адрес. MTU на узлах - 1500, и L2 MTU на стороне коммутатора я тоже не трогал. И да, вот оно:
Это уже было в образе, и я никогда не подвергал это сомнению. То есть 106 Гбит/с - это, возможно, просто одна половина порта плюс небольшой запас?
Другой стек, тот же вид сюрприза. У меня был ConnectX-6 (MT28908) под RHEL 8.4, MLNX_OFED 5.7, прошивка 20.32.2004, MFT 4.21; на дальнем конце Switch-IB 2 SB7800, а между ними разветвитель LinkX MCP7H50-H002R26, разводящий 200G на 2x100G. Порт поднялся как
и ни mlxlink -d mlx5_0 -p 1 --speeds edr, ни --speeds hdr ничего не меняли. Оказалось, что это потолок самой микросхемы, а не ошибка конфигурации: оборудование EDR формирует линки только шириной 1x или 4x, а разветвитель такого рода опирается на группировку 2x, которая появилась только с HDR. Так что либо обычный кабель 4x EDR в этот коммутатор, либо переход на HDR, если разделение обязательно.
Общий урок для breakout: сначала выясните, какую группировку линий реально может сформировать каждый конец, и только потом что-то измеряйте.
Один момент из рецепта выше стоит проговорить отдельно, потому что именно на нём люди снова теряют весь выигрыш: MTU должен совпадать и на коммутаторе тоже. Выставить 9000 на хостах, пока порты всё ещё пропускают кадры по 1500 байт, даёт вам дропы, а не пропускную способность. Задайте L2 MTU на портах CRS812 и проверьте пингом с большим payload, прежде чем перезапускать любой тест.
С IPv6 та же история. Когда обе половины адресованы, а IPv6 оставлен включённым, на порт приходится больше записей GID, и индекс, который использует ваш тест, не обязательно тот, что вы думаете. Отключение IPv6 на интерфейсах CX7 держит эту таблицу маленькой и предсказуемой между перезагрузками, что значит больше, чем кажется на слух, когда вы сравниваете разные прогоны.
Стоит иметь в виду, что порт breakout, который остаётся down, - это совершенно другой зверь по сравнению с вашим случаем. На подержанном Arista DCS-7060CX-32S (EOS 4.16.8FX-7060X) мои четыре подынтерфейса не показывали вообще никаких ошибок и просто никогда не линковались. Коробка стояла на transceiver qsfp default-mode 4x10G, тогда как дальний конец предлагал 25G, и Et17/1 оставался в errdisabled, пока скорость не выставили вручную:
В той же сессии кабель Mellanox был отклонён как неквалифицированный трансивер, и его пришлось заменить на совместимый с Arista DAC QSFP28 100GBASE-CR4. С другой стороны, коллега так и не смог поднять breakout QDD-4X100G-2P5M на QFX5220-32CD под Junos 23.2R1-S1.8-EVO в сторону коммутатора Mellanox - с профилем порта, который прошёл проверку Port Checker, и перебором всех вариантов FEC. У вас хотя бы согласуется и передаёт трафик.
Подтверждаю, порт вообще не был сломан. Я адресовал enP2p1s0f1np1 как отдельный интерфейс, выставил MTU 9000 на узлах и на портах коммутатора, отключил IPv6 на обоих интерфейсах CX7 и убрал NCCL_IB_DISABLE=1 из /etc/nccl.conf.
Две параллельные сессии iperf3, по одной на половину, теперь дают суммарно 196-198 Гбит/с. all_reduce_perf по четырём узлам сообщает о пропускной способности шины 23,76 ГБ/с, и NCCL идёт по пути RDMA, транспорта Socket в логе больше нет. NADDOD Q2Q56-400G-CU2 всё это время исправно делал свою работу.