MikroTik CRS812 breakout 400G do DGX Spark: link 200G ogranicza się do 106 Gb/s, a NCCL spada do Socket
Stawiamy cztery węzły DGX Spark pod trening rozproszony i wpięliśmy je w MikroTik CRS812-8DS-2DQ-2DDQ. Plan był taki, że jeden port 400G QSFP-DD na switchu karmi dwa węzły po 200G każdy, więc para kabli breakout obsługuje cały klaster.
- MikroTik CRS812-8DS-2DQ-2DDQ, porty QSFP-DD używane w trybie breakout
- NADDOD Q2Q56-400G-CU2, pasywny DAC QSFP-DD 400G na 2x QSFP56 200G
- węzły DGX Spark z wbudowanym ConnectX-7
- walidacja przez iperf3 i nccl-tests all_reduce_perf
Oba końce zgłaszają czysty link 200GbE, ale przepustowość siedzi trochę powyżej połowy tego:
# 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 UPNCCL wygląda gorzej niż to: all_reduce_perf zgłasza transport Socket i mniej więcej 2 GB/s przepustowości magistrali na cztery węzły, więc RDMA wyraźnie w ogóle nie jest używane.
Co już sprawdziliśmy:
- wyjąłem i osadziłem ponownie, podmieniłem kabel breakout między portami switcha, identyczne liczby
- podniosłem liczbę strumieni, suma zostaje przypięta w okolicach 106 Gb/s
- potwierdziłem, że switch zgłasza port na 200G, nie 100G
Część, do której cały czas wracam, to że jeden fizyczny port QSFP56 pokazuje się na węźle jako dwa logiczne interfejsy. Czy breakout dostarcza każdemu węzłowi tylko połowę torów, czy port 200G na tym sprzęcie ma tak właśnie wyglądać?
Comments 7
To dokładnie to, i kabel breakout jest niewinny. Na tej platformie port ConnectX-7 jest podpięty przez PCIe x4 i wystawiony jako dwie logiczne połówki, każda niosąca około 100 Gb/s. Pełne 200G pojawia się tylko wtedy, kiedy obie połówki są obciążone jednocześnie, więc przebieg iperf3 na jednym adresie, który zatrzymuje się tuż powyżej 100 Gb/s, to oczekiwany wynik, a nie awaria.
Co tutaj zadziałało:
Z obiema połówkami niosącymi ruch powinieneś wylądować blisko prędkości liniowej na tej parze, a nccl-tests all_reduce_perf zgłosi zupełnie inną klasę przepustowości magistrali, jak tylko przestanie iść przez sockety.
Zanim obwinisz kabel, jak dokładnie sterujesz tymi dwoma interfejsami? Wkleiłeś enp1s0f1np1 i enP2p1s0f1np1 jako oba UP, ale czy iperf3 uderza w oba, czy tylko w ten, który niesie adres?
Warto też wkleić: MTU na węzłach i na portach CRS812, bo 1500 mocno boli przy tej prędkości, oraz zawartość /etc/nccl.conf. Kiedy NCCL wybiera transport Socket, to prawie zawsze dlatego, że coś w tym pliku kazało mu nie dotykać ścieżki IB, a nie dlatego, że fabric jest zepsuty.
Słuszne pytania. Tylko enp1s0f1np1 ma adres, połówka enP2p1s0f1np1 jest up, ale nieskonfigurowana, i każdy dotychczasowy przebieg iperf3 szedł na ten jeden adres. MTU to 1500 na węzłach i L2 MTU po stronie switcha też nie ruszałem. I tak, jest to:
To już było w obrazie i nigdy tego nie kwestionowałem. Czyli te 106 Gb/s to być może tylko jedna połówka portu plus odrobina zapasu?
Inny stos, ale ten sam kształt zaskoczenia. U mnie był ConnectX-6 (MT28908) pod RHEL 8.4, MLNX_OFED 5.7, firmware 20.32.2004, MFT 4.21; po drugiej stronie Switch-IB 2 SB7800, a między nimi splitter LinkX MCP7H50-H002R26 schodzący ze 200G na 2x100G. Port wstał jako
i ani mlxlink -d mlx5_0 -p 1 --speeds edr, ani --speeds hdr niczego nie zmieniały. Okazało się, że to sufit w krzemie, a nie błąd konfiguracji: sprzęt EDR tworzy linki tylko o szerokości 1x albo 4x, a splitter tego rodzaju opiera się na grupowaniu 2x, które przyszło razem z HDR. Więc albo zwykły kabel 4x EDR do tego switcha, albo przejście na HDR, jeśli split jest konieczny.
Morał dla breakoutów ogólnie: ustal, jakie grupowanie torów każdy koniec faktycznie potrafi utworzyć, zanim cokolwiek zmierzysz.
Jedna rzecz z przepisu powyżej zasługuje na dopowiedzenie, bo to właśnie w tym miejscu ludzie znowu tracą zyski: MTU musi się zgadzać też na switchu. Ustawienie 9000 na hostach, podczas gdy porty nadal przepuszczają ramki 1500-bajtowe, kupuje ci straty, a nie przepustowość. Ustaw L2 MTU na portach CRS812 i zweryfikuj dużym pingiem z dużym payloadem, zanim ponownie uruchomisz jakikolwiek test.
Z IPv6 jest ta sama historia. Z obiema połówkami zaadresowanymi i IPv6 zostawionym włączonym dostajesz dodatkowe wpisy GID na port, a indeks, którego twój test ma użyć, niekoniecznie jest tym, który myślisz. Wyłączenie IPv6 na interfejsach CX7 trzyma tę tabelę małą i przewidywalną między restartami, co ma większe znaczenie, niż brzmi, kiedy porównujesz przebiegi.
Warto pamiętać, że port breakout, który zostaje down, to zupełnie inne zwierzę niż twoje. Na używanym Aristcie DCS-7060CX-32S (EOS 4.16.8FX-7060X) moje cztery subinterfejsy nie pokazywały żadnych błędów i po prostu nigdy się nie łączyły. Urządzenie siedziało na transceiver qsfp default-mode 4x10G, podczas gdy druga strona prezentowała 25G, i Et17/1 zostawał errdisabled, dopóki prędkość nie została ustawiona ręcznie:
W tej samej sesji kabel Mellanox został odrzucony jako niezakwalifikowany transceiver i trzeba było go zamienić na kompatybilny z Aristą DAC 100GBASE-CR4 QSFP28. Na drugim biegunie kolega nigdy nie postawił breakoutu QDD-4X100G-2P5M na QFX5220-32CD z Junosem 23.2R1-S1.8-EVO w stronę switcha Mellanox, mimo profilu portu zwalidowanego przez Port Checker i wypróbowania każdego wariantu FEC. Twój przynajmniej negocjuje i przepuszcza ruch.
Potwierdzam, i port nigdy nie był zepsuty. Zaadresowałem enP2p1s0f1np1 jako własny interfejs, ustawiłem MTU 9000 na węzłach i na portach switcha, wyłączyłem IPv6 na obu interfejsach CX7 i usunąłem NCCL_IB_DISABLE=1 z /etc/nccl.conf.
Dwie równoległe sesje iperf3, po jednej na połówkę, dają teraz 196-198 Gb/s sumy. all_reduce_perf na czterech węzłach zgłasza 23.76 GB/s przepustowości magistrali, a NCCL jest na ścieżce RDMA, w logu nie ma już transportu Socket. NADDOD Q2Q56-400G-CU2 przez cały czas robił swoje.