Document NCCL alltoall counter probe

2026-05-23 17:13:03 +08:00 · 2026-05-23 17:13:03 +08:00 · 890e623be4
commit 890e623be4
parent 17441a4583
3 changed files with 94 additions and 9 deletions
--- a/reports_multinode_nccl_alltoall_tuning_20260523.md
+++ b/reports_multinode_nccl_alltoall_tuning_20260523.md
@ -10,7 +10,9 @@

 `NCCL_PXN_DISABLE=1` 是本轮唯一有效正向参数，可以把 8 卡 alltoall 从约 `30.06 GB/s` 提升到约 `37.24 GB/s`。纳入正式 PDF 矩阵配置后，8 卡 alltoall 原始报告结果为 `36.70 GB/s peak` / `36.74 GB/s avg`。

-补充计数器探测显示，`NCCL_PXN_DISABLE=1` 的实际作用是把 alltoall 流量重新均匀分配到 4 条 400G rail 上。baseline 下 `mlx5_0/6` 与 `mlx5_1/7` 的流量约为 3:1；禁用 PXN 后四条 HCA 均为约 `590.98 GB`。但每条 rail 的实际吞吐仍只有约 `19.82 GB/s`，没有打满 400G rail。
+补充计数器探测显示，`NCCL_PXN_DISABLE=1` 的实际作用是把 alltoall 流量重新均匀分配到 4 条 400G rail 上。baseline 下 `mlx5_0/6` 与 `mlx5_1/7` 的流量约为 3:1；禁用 PXN 后四条 HCA 均衡。但每条 rail 的实际吞吐仍只有约 `19-20 GB/s`，没有打满 400G rail。
+
+复测错误/拥塞 counter 后，没有看到 discard、链路错误、RoCE 重传、slow restart 或 packet sequence error 增长；主要非零异常是部分端口 `port_xmit_wait`。所以当前不支持“链路坏包/重传导致慢”的判断，更像发送等待/credit 等待、交换侧调度/拥塞控制，或 NCCL internal alltoall 通信模式效率不足。

 这个提升有实际价值，但仍远低于 PDF 参考 `76.54 GB/s`。其他参数没有改善，部分明显变差：

@ -60,6 +62,18 @@
 | baseline | `mlx5_0/6` 约 `885 GB`，`mlx5_1/7` 约 `295 GB` | `30.04 GB/s` |
 | `NCCL_PXN_DISABLE=1` | 四条 HCA 均约 `591 GB` | `36.95 GB/s` |

+### 错误/等待 counter 复测
+
+PXN disabled 复测结果：
+
+| 观察项 | 结果 |
+|--------|------|
+| `Avg bus bandwidth` | `36.4512 GB/s` |
+| 每条 HCA 流量 | 约 `712.18-712.28 GiB`，四条 rail 均衡 |
+| discard / rcv error / symbol error / link down / link recovery | `0` 增量 |
+| RoCE retrans / slow restart / packet sequence error / out of sequence | `0` 增量 |
+| `port_xmit_wait` | `mlx5_1`、`mlx5_7` 有增长，约 `15.65M-23.49M` |
+
 ## 正式配置更新

 `configs/multinode_nccl_nccl227_pdf_matrix.yaml` 已对 2 nodes x 8 GPUs 的 alltoall 增加：
@ -81,4 +95,4 @@ op_env:
 1. PXN 在当前拓扑下对 8 卡 alltoall 有负面影响，禁用后有约 `22-24%` 提升。
 2. 禁用 PXN 可以修复 rail 分布不均衡，但无法打满每条 400G rail。
 3. 禁用 PXN 后仍只有 PDF 目标的一半左右，剩余差距不是单一 NCCL 环境变量可以补齐。
-4. 后续重点仍应放在 NCCL net plugin/SHARP、交换网络策略、路由/拥塞和 NCCL internal alltoall 实现效率。
+4. 后续重点仍应放在 NCCL net plugin/SHARP、交换网络策略、credit/拥塞等待和 NCCL internal alltoall 实现效率。
--- a/reports_multinode_nccl_counter_probe_20260523.md
+++ b/reports_multinode_nccl_counter_probe_20260523.md
@ -14,7 +14,9 @@

 8 卡 alltoall 仍只有 `30 GB/s busbw`，不是 HCA 顺序导致。HCA 顺序 sweep 都稳定在 `30.02-30.07 GB/s`。计数器显示 alltoall 流量主要压在 `mlx5_0` 和 `mlx5_6` 上，`mlx5_1` 和 `mlx5_7` 只有约三分之一流量，说明剩余问题更像 NCCL alltoall rail 分布、路由、拥塞、NCCL net plugin/SHARP 或网络侧策略问题。

-补充测试显示，`NCCL_PXN_DISABLE=1` 可以把 alltoall 流量均匀分配到四条 HCA，并将 busbw 提升到约 `36.95 GB/s`。不过每条 400G rail 仍只有约 `19.82 GB/s`，没有达到裸 RDMA 单 rail 能力。
+补充测试显示，`NCCL_PXN_DISABLE=1` 可以把 alltoall 流量均匀分配到四条 HCA，并将 busbw 提升到约 `36.5-37.0 GB/s`。不过每条 400G rail 仍只有约 `19-20 GB/s`，没有达到裸 RDMA 单 rail 能力。
+
+进一步抓 `counters`/`hw_counters` 后，未看到 discard、CRC/符号错误、packet sequence error、RoCE retrans、slow restart 等错误类计数增长；只看到部分端口 `port_xmit_wait` 增长。也就是说，PXN disabled 后剩余问题不是明显的链路坏包/重传，而更像发送等待、信用/拥塞等待、交换网络调度或 NCCL internal alltoall 通信模式效率问题。

 ## 裸 RDMA 4 rail 并发

@ -108,11 +110,66 @@ NCCL 输出：

 判断：禁用 PXN 可以修复 rail 分布不均衡，但不能让 alltoall 打满当前 4 条 400G rail。

+### PXN disabled 错误/拥塞 counter 复测
+
+复测命令仍为 2 nodes x 8 GPUs，`alltoall_perf -b 16G -e 16G -w 10 -n 10`，并使用：
+
+```bash
+NCCL_PXN_DISABLE=1
+NCCL_IB_HCA=mlx5_0,mlx5_1,mlx5_6,mlx5_7
+NCCL_NET_PLUGIN=none
+NCCL_NET_GDR_LEVEL=5
+NCCL_NET_GDR_READ=1
+NCCL_DMABUF_ENABLE=0
+```
+
+NCCL 输出：
+
+| Metric | Value |
+|--------|-------|
+| `algbw` | `39.04 / 38.72 GB/s` |
+| `busbw` | `36.60 / 36.30 GB/s` |
+| `Avg bus bandwidth` | `36.4512 GB/s` |
+
+流量分布保持均衡：
+
+| Host | HCA | Xmit GiB | Recv GiB |
+|------|-----|----------|----------|
+| aikubeworker0012 | `mlx5_0` | `712.28` | `712.19` |
+| aikubeworker0012 | `mlx5_1` | `712.27` | `712.27` |
+| aikubeworker0012 | `mlx5_6` | `712.28` | `712.18` |
+| aikubeworker0012 | `mlx5_7` | `712.27` | `712.27` |
+| aikubeworker0016 | `mlx5_0` | `712.23` | `712.27` |
+| aikubeworker0016 | `mlx5_1` | `712.23` | `712.27` |
+| aikubeworker0016 | `mlx5_6` | `712.23` | `712.27` |
+| aikubeworker0016 | `mlx5_7` | `712.23` | `712.27` |
+
+错误类 counter 增量：
+
+| Counter group | Result |
+|---------------|--------|
+| `port_xmit_discards`, `port_rcv_errors`, `port_rcv_remote_physical_errors`, `port_rcv_switch_relay_errors` | `0` |
+| `symbol_error`, `link_error_recovery`, `link_downed`, `local_link_integrity_errors`, `excessive_buffer_overrun_errors` | `0` |
+| `roce_adp_retrans`, `roce_adp_retrans_to`, `roce_slow_restart*` | `0` |
+| `packet_seq_err`, `out_of_sequence`, `out_of_buffer`, `duplicate_request`, `implied_nak_seq_err` | `0` |
+| `local_ack_timeout_err`, `req_transport_retries_exceeded`, `rnr_nak_retry_err` | `0` |
+
+非零等待类 counter：
+
+| Host | HCA | `port_xmit_wait` delta |
+|------|-----|------------------------|
+| aikubeworker0012 | `mlx5_1` | `23,492,853` |
+| aikubeworker0012 | `mlx5_7` | `17,420,720` |
+| aikubeworker0016 | `mlx5_1` | `20,428,901` |
+| aikubeworker0016 | `mlx5_7` | `15,650,027` |
+
+判断：PXN disabled 后 alltoall 没有明显链路错误、重传或丢包证据；剩余性能缺口更偏向 `port_xmit_wait` 指向的发送等待/信用等待、交换网络拥塞控制/调度，或 NCCL internal alltoall 在当前拓扑下的通信模式效率。
+
 ## 判断

 1. 裸 RDMA 4 rail 可以并发跑到约 `184.62 GB/s`，网络基础带宽不是单 rail 瓶颈。
 2. 8 卡 allreduce 当前不是软件参数小调能解决的问题，性能已经贴近当前 4 条 400G rail 的物理带宽上限。
-3. 8 卡 alltoall 仍明显异常，且不是 HCA 顺序问题；需要继续从 NCCL alltoall rail 分布、网络路由/拥塞、NCCL net plugin/SHARP、交换机侧策略排查。
+3. 8 卡 alltoall 仍明显异常，且不是 HCA 顺序问题；PXN disabled 后 rail 已均衡，但仍出现 `port_xmit_wait`，需要继续从网络拥塞/信用等待、交换机侧策略、NCCL alltoall 模式、NCCL net plugin/SHARP 排查。
 4. `NCCL_PXN_DISABLE=1` 可改善 8 卡 alltoall 的 rail 均衡性和性能，但无法补齐到 PDF 目标。
 5. 如果验收必须达到 PDF 的 2 机 16 卡 `491.84/76.54 GB/s`，需要确认当前两台机器是否具备与 PDF 参考环境同等的有效跨节点 rail 数量和交换网络能力。
 6. 两台机器当前均未发现 `libnccl-net.so` 或 SHARP/HCOLL 包，NCCL 使用 internal IB plugin；如果目标值依赖 NCCL net plugin/SHARP，需要先补齐对应运行环境。
--- a/reports_multinode_nccl_diagnosis_20260523.md
+++ b/reports_multinode_nccl_diagnosis_20260523.md
@ -16,7 +16,7 @@

 按 `sx算力节点跨Leaf NCCL测试报告.pdf` 的矩阵继续对齐后，发现 2 机 4 卡档位的核心问题是默认 GPU 选择不符合 GPU-NIC 亲和性。显式选择 `CUDA_VISIBLE_DEVICES=0,1,4,5` 后，2 机 4 卡 allreduce 可以恢复到 `333-335 GB/s` 区间，接近 PDF 的 `335.48 GB/s`；alltoall 配合 PDF 固定 NCCL 参数可到 `72.93 GB/s`，接近 PDF 的 `73.73 GB/s`。但 2 机 8 卡档位仍只有 allreduce `354.02 GB/s`、alltoall `30.04 GB/s`，与 PDF 的 `491.84/76.54 GB/s` 差距明显。

-进一步 sweep 8 卡 alltoall 网络参数后，`NCCL_PXN_DISABLE=1` 是唯一有效正向项。正式矩阵配置已对 2 机 8 GPU 的 alltoall 单独加入该变量，8 卡 alltoall 从约 `30.04 GB/s` 提升到 `36.70 GB/s` peak / `36.74 GB/s` avg，但仍低于 PDF 参考 `76.54 GB/s`。
+进一步 sweep 8 卡 alltoall 网络参数后，`NCCL_PXN_DISABLE=1` 是唯一有效正向项。正式矩阵配置已对 2 机 8 GPU 的 alltoall 单独加入该变量，8 卡 alltoall 从约 `30.04 GB/s` 提升到 `36.70 GB/s` peak / `36.74 GB/s` avg，但仍低于 PDF 参考 `76.54 GB/s`。复测端口 counter 后，PXN disabled 下 4 条 rail 的流量已均衡，且没有明显链路错误、丢包、RoCE 重传或 slow restart；只在部分端口看到 `port_xmit_wait` 增长，剩余差距更像发送等待/信用等待、交换网络策略或 NCCL internal alltoall 通信模式效率问题。

 同时，`nccl-gpu-2` 的 SSH 入口曾因未认证连接过多触发 `MaxStartups` 随机拒绝，导致 `mpirun` 拉起远端 rank 失败。已经做了临时 SSHD 缓解并拿到有效的 2 节点 x 8 GPU allreduce/alltoall 报告。

@ -36,6 +36,7 @@
 12. 增加 topology 级 `cuda_visible_devices`、`env`、`op_env` 配置能力，支持按 GPU/NIC 亲和性和不同 NCCL op 分别设置环境变量。
 13. 生成 PDF 矩阵式原始报告 `reports_multinode_nccl_pdf_matrix_nccl227.md`，覆盖 2 机 1/2/4/8 GPU per node。
 14. 对 8 卡 alltoall 做 NCCL 网络参数 sweep，并将有效项 `NCCL_PXN_DISABLE=1` 固化到 PDF 矩阵配置。
+15. 对 PXN disabled 后的 8 卡 alltoall 抓取 `counters`/`hw_counters` 增量，确认 rail 已均衡且无明显错误/重传，剩余异常主要伴随 `port_xmit_wait`。

 ## 关键证据

@ -292,7 +293,19 @@ PXN disabled 计数器显示该参数确实修复了 rail 分布：
 | baseline | `mlx5_0/6` 约 `885 GB`，`mlx5_1/7` 约 `295 GB` | `30.04 GB/s` |
 | `NCCL_PXN_DISABLE=1` | 四条 HCA 均约 `591 GB` | `36.95 GB/s` |

-但禁用 PXN 后每条 400G rail 仍只有约 `19.82 GB/s`，没有接近裸 RDMA 单 rail 的 `347-387 Gb/s`。因此它解决的是 rail 分布不均衡的一部分，不是全部 alltoall 性能问题。
+但禁用 PXN 后每条 400G rail 仍只有约 `19-20 GB/s`，没有接近裸 RDMA 单 rail 的 `347-387 Gb/s`。因此它解决的是 rail 分布不均衡的一部分，不是全部 alltoall 性能问题。
+
+复测 PXN disabled alltoall 时继续抓 `counters`/`hw_counters`：
+
+| 观察项 | 结果 |
+|--------|------|
+| alltoall `Avg bus bandwidth` | `36.4512 GB/s` |
+| 每条 HCA 流量 | 约 `712.18-712.28 GiB`，四条 rail 均衡 |
+| discard / rcv error / symbol error / link down / link recovery | `0` 增量 |
+| RoCE retrans / slow restart / packet sequence error / out of sequence | `0` 增量 |
+| `port_xmit_wait` | `mlx5_1`、`mlx5_7` 有增长，约 `15.65M-23.49M` |
+
+判断：当前没有明显坏链路、丢包或重传证据；`port_xmit_wait` 更像发送侧等待 credit/拥塞控制/交换侧调度，或者 NCCL internal alltoall 在当前拓扑下没有把 rail 吞吐打起来。

 ### 8. 8 卡链路计数器与物理上限判断

@ -391,9 +404,10 @@ libnccl-dev
 - 8 卡 allreduce `algbw ~= 189 GB/s`，接近当前 4 x 400G HCA 的理论单向合计 `200 GB/s`
 - 裸 RDMA 4 rail 并发 `ib_write_bw` 合计 `1476.95 Gb/s` / `184.62 GB/s`
 - PDF 8 卡 allreduce `491.84 GB/s busbw` 反推需要约 `262 GB/s algbw`，超过当前 4 x 400G 的物理单向总带宽
- 8 卡 alltoall 端口计数器显示 rail 分布不均，且 HCA 顺序 sweep 无改善
+- 8 卡 alltoall baseline 端口计数器显示 rail 分布不均，且 HCA 顺序 sweep 无改善
 - 当前环境缺失 NCCL net plugin/SHARP，NCCL 只能使用 internal IB plugin
 - `NCCL_PXN_DISABLE=1` 可将 8 卡 alltoall 提升到约 `36.7 GB/s`，并修复 rail 分布不均，但仍不到 PDF 参考值的一半
+- PXN disabled 复测没有看到 discard、链路错误、RoCE 重传、slow restart、packet sequence error 等错误类 counter 增长；主要异常信号是部分端口 `port_xmit_wait`

 ### 阻塞 3：`nccl-gpu-2` SSH 存在外部连接压力

@ -414,9 +428,9 @@ libnccl-dev
 4. 4 卡 allreduce 建议继续让 NCCL 自动选择 channel/QP；4 卡 alltoall 如果要贴近 PDF，可单独套 `NCCL_IB_QPS_PER_CONNECTION=4`、`NCCL_MIN_NCHANNELS=4`、`NCCL_IB_SPLIT_DATA_ON_QPS=1`。
 5. 8 卡 per node 不建议套上述固定参数，会降低 allreduce；继续用 auto。
 6. 尝试安装或启用匹配当前 OFED/driver 的 NCCL net plugin/SHARP；当前日志显示 `Could not find: libnccl-net.so`，NCCL 使用的是 internal IB plugin。
-7. 核对跨 Leaf 链路的 rail mapping、交换机端口速率、路由和拥塞计数，确认 4 个 400Gb/s HCA 是否都在跨节点通信中充分利用。
+7. 核对跨 Leaf 链路的 rail mapping、交换机端口速率、路由、credit/拥塞等待与交换机侧队列计数，解释 PXN disabled 后 `port_xmit_wait` 增长但无错误/重传的原因。
 8. 确认当前 PDF 的 `491.84/76.54 GB/s` 是否要求当前这两台节点在只有 4 条 400G rail 的形态下也达到；如果要求一致，需要网络/硬件侧继续介入。
-9. 对 8 卡 alltoall，重点查 NCCL rail 分布、交换机 ECMP/自适应路由、拥塞计数、SHARP/NCCL net plugin，而不是继续调 `NCCL_IB_HCA` 顺序。
+9. 对 8 卡 alltoall，重点查交换机 ECMP/自适应路由、拥塞/credit 等待、SHARP/NCCL net plugin 和 NCCL internal alltoall 行为；`NCCL_IB_HCA` 顺序与 rail 分布本身已经不是当前主问题。

 ## 当前可交付物