Breakout 400G MikroTik CRS812 ke DGX Spark: link 200G mentok di 106 Gb/s dan NCCL fallback ke Socket
Kami sedang menyiapkan empat node DGX Spark untuk distributed training dan menggantungkan mereka ke MikroTik CRS812-8DS-2DQ-2DDQ. Rencananya satu port 400G QSFP-DD di switch memberi makan dua node di 200G masing-masing, jadi beberapa kabel breakout mencakup seluruh cluster.
- MikroTik CRS812-8DS-2DQ-2DDQ, port QSFP-DD dipakai dalam mode breakout
- NADDOD Q2Q56-400G-CU2, DAC pasif QSFP-DD 400G ke 2x QSFP56 200G
- Node DGX Spark dengan ConnectX-7 onboard
- validasi pakai iperf3 dan nccl-tests all_reduce_perf
Kedua ujung melaporkan link 200GbE yang bersih, tapi throughput-nya diam di sedikit di atas separuhnya:
# 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 kelihatannya lebih buruk dari itu: all_reduce_perf melaporkan Socket transport dan bus bandwidth sekitar 2 GB/s di keempat node, jadi RDMA jelas sama sekali tidak dipakai.
Yang sudah kami cek:
- pasang ulang dan tukar kabel breakout-nya antar port switch, angkanya identik
- naikkan jumlah stream-nya, aggregate-nya tetap menempel di sekitar 106 Gb/s
- konfirmasi switch-nya melaporkan port-nya di 200G, bukan 100G
Bagian yang terus saya pikirkan adalah satu port fisik QSFP56 muncul sebagai dua interface logis di node-nya. Apa breakout-nya cuma mengirim separuh lane ke tiap node, atau memang begitu seharusnya tampilan port 200G di hardware ini?
Comments 7
Itu persis penyebabnya, dan kabel breakout-nya tidak bersalah. Di platform ini port ConnectX-7 disambungkan lewat PCIe x4 dan diekspos sebagai dua paruh logis, masing-masing membawa sekitar 100 Gb/s. 200G penuh cuma muncul kalau kedua paruhnya dibebani bersamaan, jadi satu run iperf3 dengan satu alamat yang berhenti persis di atas 100 Gb/s itu hasil yang diharapkan, bukan kegagalan.
Yang membuat ini berhasil di sini:
Dengan kedua paruhnya membawa traffic, kamu seharusnya mendarat dekat line rate di pasangan itu, dan nccl-tests all_reduce_perf akan melaporkan kelas bus bandwidth yang sama sekali berbeda begitu dia berhenti lewat socket.
Sebelum menyalahkan kabelnya, sebenarnya bagaimana cara kamu men-drive kedua interface itu? Kamu tempel enp1s0f1np1 dan enP2p1s0f1np1 sebagai UP berdua, tapi apa iperf3-nya mengenai keduanya, atau cuma yang mana pun yang punya alamat?
Perlu diposting juga: MTU di node-nya dan di port CRS812-nya, karena 1500 sakit banget di rate segini, dan isi /etc/nccl.conf. Kalau NCCL memilih Socket transport itu hampir selalu karena ada sesuatu di file itu yang bilang jangan sentuh jalur IB-nya, bukan karena fabric-nya rusak.
Pertanyaan yang wajar. Cuma enp1s0f1np1 yang punya alamat, paruh enP2p1s0f1np1 up tapi belum dikonfigurasi, dan setiap run iperf3 sejauh ini pergi ke alamat tunggal itu. MTU-nya 1500 di node-node-nya dan saya juga belum menyentuh L2 MTU di sisi switch-nya. Dan ya, ini dia:
Itu sudah ada di image-nya dan saya tidak pernah mempertanyakannya. Jadi 106 Gb/s itu kemungkinan cuma satu paruh dari port-nya plus sedikit headroom?
Stack yang berbeda, bentuk kejutan yang sama. Sisi saya ConnectX-6 (MT28908) di bawah RHEL 8.4, MLNX_OFED 5.7, firmware 20.32.2004, MFT 4.21; ujung satunya Switch-IB 2 SB7800, dan di antara keduanya splitter LinkX MCP7H50-H002R26 yang menurunkan 200G jadi 2x100G. Port-nya naik sebagai
dan baik mlxlink -d mlx5_0 -p 1 --speeds edr maupun --speeds hdr tidak mengubah apa-apa. Ternyata itu plafon di silikonnya, bukan kesalahan konfigurasi: perangkat EDR cuma membentuk link selebar 1x atau 4x, dan splitter jenis itu bersandar pada grouping 2x, yang baru datang bersama HDR. Jadi pilihannya kabel EDR 4x biasa ke switch itu, atau pindah ke HDR kalau split-nya memang wajib.
Moral untuk breakout secara umum: cari tahu dulu lane grouping apa yang benar-benar bisa dibentuk masing-masing ujung, sebelum mengukur apa pun.
Satu hal dari resep di atas perlu dijelaskan lagi, karena di situlah orang sering kehilangan keuntungannya lagi: MTU-nya harus cocok di switch-nya juga. Set 9000 di host-nya sementara port-nya masih meloloskan frame 1500 byte cuma membeli drop, bukan throughput. Set L2 MTU di port CRS812-nya dan verifikasi dengan ping payload besar sebelum menjalankan ulang tes apa pun.
Soal IPv6 ceritanya sama. Dengan kedua paruhnya dialamati dan IPv6 masih menyala, kamu dapat entry GID ekstra per port, dan indeks yang diberi tahu ke tes kamu untuk dipakai belum tentu yang kamu kira. Mematikan IPv6 di interface CX7-nya menjaga tabel itu tetap kecil dan bisa diprediksi lintas reboot, yang lebih penting dari kedengarannya waktu kamu membandingkan hasil run.
Perlu diingat, port breakout yang tetap down itu hewan yang sama sekali berbeda dari punya kamu. Di Arista DCS-7060CX-32S bekas (EOS 4.16.8FX-7060X) empat sub-interface saya sama sekali tidak menunjukkan error dan cuma tidak pernah link. Box-nya diam di transceiver qsfp default-mode 4x10G sementara ujung satunya menyodorkan 25G, dan Et17/1 tetap errdisabled sampai rate-nya di-set manual:
Di sesi yang sama satu kabel Mellanox ditolak sebagai transceiver yang tidak qualified dan harus diganti dengan DAC QSFP28 100GBASE-CR4 yang Arista-compatible. Di ekstrem yang lain, seorang kolega tidak pernah berhasil menaikkan breakout QDD-4X100G-2P5M di QFX5220-32CD yang menjalankan Junos 23.2R1-S1.8-EVO ke arah switch Mellanox, dengan port profile yang sudah divalidasi Port Checker dan semua varian FEC sudah dicoba. Punya kamu setidaknya negotiate dan melewatkan traffic.
Terkonfirmasi, dan port-nya memang tidak pernah rusak. Saya alamati enP2p1s0f1np1 sebagai interface-nya sendiri, set MTU 9000 di node-node dan port switch-nya, matikan IPv6 di kedua interface CX7-nya, dan hapus NCCL_IB_DISABLE=1 dari /etc/nccl.conf.
Dua sesi iperf3 paralel, satu per paruh, sekarang memberikan aggregate 196-198 Gb/s. all_reduce_perf di keempat node melaporkan bus bandwidth 23.76 GB/s dan NCCL ada di jalur RDMA, tidak ada lagi Socket transport di log-nya. NADDOD Q2Q56-400G-CU2-nya sudah melakukan tugasnya sepanjang waktu.