MikroTik CRS812 400G breakout'tan DGX Spark'a: 200G link 106 Gb/s'te tavan yapıyor, NCCL da Socket'e düşüyor
Dağıtık eğitim için dört DGX Spark node'u ayağa kaldırıyoruz ve onları bir MikroTik CRS812-8DS-2DQ-2DDQ'ya astık. Plan, switch'te bir 400G QSFP-DD portunun iki node'u 200G'den beslemesiydi, yani birkaç breakout kablo tüm cluster'ı kapsayacaktı.
- MikroTik CRS812-8DS-2DQ-2DDQ, breakout modda kullanılan QSFP-DD portları
- NADDOD Q2Q56-400G-CU2, QSFP-DD 400G'den 2x QSFP56 200G'ye pasif DAC
- onboard ConnectX-7'li DGX Spark node'ları
- iperf3 ve nccl-tests all_reduce_perf ile doğrulama
İki uç da temiz bir 200GbE link raporluyor, ama throughput bunun biraz üzerinde yarısında oturuyor:
# 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 bundan daha kötü görünüyor: all_reduce_perf, dört node boyunca Socket transport ve kabaca 2 GB/s bus bandwidth raporluyor, yani RDMA'nın hiç kullanılmadığı açık.
Şimdiye kadar kontrol ettiklerimiz:
- breakout kabloyu yeniden oturttuk ve switch portları arasında değiştirdik, rakamlar birebir aynı
- stream sayısını artırdık, toplam 106 Gb/s civarında sabit kalıyor
- switch'in portu 100G değil 200G raporladığını doğruladık
Sürekli geri döndüğüm kısım, tek bir fiziksel QSFP56 portunun node'da iki logical interface olarak görünmesi. Breakout her node'a lane'lerin sadece yarısını mı veriyor, yoksa bu donanımda bir 200G portu böyle mi görünmesi gerekiyor?
Comments 7
Durum tam olarak bu, breakout kablosu da masum. Bu platformda ConnectX-7 portu PCIe x4 üzerinden bağlı ve her biri yaklaşık 100 Gb/s taşıyan iki logical yarı olarak gösteriliyor. Tam 200G ancak iki yarı da aynı anda yüklendiğinde ortaya çıkıyor, yani tek adresli bir iperf3 çalıştırmasının 100 Gb/s'in hemen üzerinde durması bir arıza değil, beklenen sonuç.
Burada işe yarayan:
İki yarı da trafik taşırken çift üzerinde line rate'e yakın bir yere inmelisin, nccl-tests all_reduce_perf de socket'ler üzerinden gitmeyi bıraktığında tamamen farklı bir bus bandwidth sınıfı raporlayacak.
Kabloyu suçlamadan önce, o iki interface'i tam olarak nasıl sürüyorsun? enp1s0f1np1 ve enP2p1s0f1np1'i ikisi de UP olarak yapıştırdın, ama iperf3 ikisine de mi vuruyor, yoksa sadece adres taşıyana mı?
Paylaşmakta fayda olan başka şeyler: node'lardaki ve CRS812 portlarındaki MTU, çünkü bu hızda 1500 ciddi zarar veriyor, bir de /etc/nccl.conf'un içeriği. NCCL Socket transport'u seçtiğinde bunun sebebi neredeyse her zaman o dosyadaki bir şeyin ona IB yoluna dokunmamasını söylemesidir, fabric'in bozuk olması değil.
Haklı sorular. Sadece enp1s0f1np1'in bir adresi var, enP2p1s0f1np1 yarısı up ama konfigüre edilmemiş, şimdiye kadarki her iperf3 çalıştırması da o tek adrese gitti. Node'larda MTU 1500 ve switch tarafındaki L2 MTU'ya da hiç dokunmadım. Ve evet, işte orada:
Bu zaten image'ın içindeydi ve hiç sorgulamadım. Yani 106 Gb/s muhtemelen sadece portun bir yarısı artı biraz headroom mu?
Farklı bir stack, aynı şekilde bir sürpriz. Benim tarafım RHEL 8.4 altında bir ConnectX-6 (MT28908), MLNX_OFED 5.7, firmware 20.32.2004, MFT 4.21 idi; karşı uç bir Switch-IB 2 SB7800, ikisinin arasında da 200G'yi 2x100G'ye indiren bir LinkX MCP7H50-H002R26 splitter'ı. Port şöyle geldi:
ne mlxlink -d mlx5_0 -p 1 --speeds edr ne de --speeds hdr bir şeyi değiştirdi. Bir config hatasından çok silikonda bir tavan olduğu ortaya çıktı: EDR donanımı linkleri yalnızca 1x veya 4x genişlikte kurar, bu tür bir splitter da HDR ile gelen 2x gruplamaya yaslanır. Yani ya o switch'e düz bir 4x EDR kablo, ya da bölme şartsa HDR'ye geçmek.
Genel olarak breakout'lar için ahlaki ders: herhangi bir şey ölçmeden önce her ucun gerçekte hangi lane gruplamasını kurabildiğini çöz.
Yukarıdaki tarifteki bir şeyin açıkça söylenmesi gerekiyor, çünkü insanların kazanımları tekrar kaybettiği yer burası: MTU'nun switch'te de eşleşmesi gerekiyor. Portlar hâlâ 1500 byte'lık frame geçirirken host'larda 9000 ayarlamak sana throughput yerine drop kazandırır. CRS812 portlarında L2 MTU'yu ayarla ve herhangi bir testi tekrar çalıştırmadan önce büyük payload'lu bir ping ile doğrula.
IPv6 konusu da aynı hikaye. İki yarı da adreslenmişken IPv6 açık bırakılırsa port başına ekstra GID girişleri olur, testinin kullanması söylenen index de senin düşündüğün olmayabilir. CX7 interface'lerinde IPv6'yı kapatmak o tabloyu küçük ve reboot'lar arasında öngörülebilir tutar, bu da koşuları karşılaştırırken kulağa geldiğinden daha çok önemlidir.
Down kalan bir breakout portunun seninkinden tamamen farklı bir hayvan olduğunu akılda tutmakta fayda var. İkinci el bir Arista DCS-7060CX-32S'te (EOS 4.16.8FX-7060X) benim dört sub-interface'im hiç hata göstermedi ve basitçe hiç linklenmedi. Kutu transceiver qsfp default-mode 4x10G'de otururken karşı uç 25G sunuyordu, Et17/1 de hız elle ayarlanana kadar errdisabled kaldı:
Aynı oturumda bir Mellanox kablo unqualified bir transceiver olarak reddedildi ve Arista-uyumlu bir 100GBASE-CR4 QSFP28 DAC ile değiştirilmesi gerekti. Diğer uçta, bir meslektaş bir Mellanox switch'e doğru Junos 23.2R1-S1.8-EVO çalıştıran bir QFX5220-32CD'de, Port Checker'ın doğruladığı bir port profile ve denenen her FEC varyantıyla bir QDD-4X100G-2P5M breakout'unu hiç ayağa kaldıramadı. Seninki en azından negotiate oluyor ve trafik geçiriyor.
Doğrulandı, port hiç bozuk değildi. enP2p1s0f1np1'i kendi interface'i olarak adresledim, node'larda ve switch portlarında MTU 9000 ayarladım, iki CX7 interface'inde de IPv6'yı kapattım ve NCCL_IB_DISABLE=1'i /etc/nccl.conf'tan çıkardım.
Yarı başına bir tane olmak üzere iki paralel iperf3 oturumu şimdi 196-198 Gb/s toplam veriyor. Dört node boyunca all_reduce_perf 23.76 GB/s bus bandwidth raporluyor, NCCL de RDMA yolunda, logda artık Socket transport yok. NADDOD Q2Q56-400G-CU2 zaten baştan beri işini yapıyormuş.