Compare NCCL allreduce alltoall counters

reports_multinode_nccl_alltoall_tuning_20260523.md

@@ -12,7 +12,7 @@
 
 补充计数器探测显示，`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 通信模式效率不足。
+复测错误/拥塞 counter 后，没有看到 discard、链路错误、RoCE 重传、slow restart 或 packet sequence error 增长；主要非零异常是部分端口 `port_xmit_wait`。不过 allreduce 对照在 `354 GB/s busbw` 时也会出现同类 `port_xmit_wait`，所以当前不支持“链路坏包/重传导致慢”的判断，也不能只用 `port_xmit_wait` 解释 alltoall 低吞吐。更可能的方向是 NCCL internal alltoall 通信模式效率、交换侧调度/拥塞控制，或缺少 NCCL net plugin/SHARP。
 
 这个提升有实际价值，但仍远低于 PDF 参考 `76.54 GB/s`。其他参数没有改善，部分明显变差：
 
@@ -74,6 +74,15 @@ PXN disabled 复测结果：
 | RoCE retrans / slow restart / packet sequence error / out of sequence | `0` 增量 |
 | `port_xmit_wait` | `mlx5_1`、`mlx5_7` 有增长，约 `15.65M-23.49M` |
 
+allreduce 对照：
+
+| 观察项 | 结果 |
+|--------|------|
+| `Avg bus bandwidth` | `354.366 GB/s` |
+| 每条 HCA 流量 | 约 `178.03-178.07 GiB`，四条 rail 均衡 |
+| 错误/重传类 counter | `0` 增量 |
+| `port_xmit_wait` | `mlx5_1`、`mlx5_7` 有增长，约 `6.11M-6.59M` |
+
 ## 正式配置更新
 
 `configs/multinode_nccl_nccl227_pdf_matrix.yaml` 已对 2 nodes x 8 GPUs 的 alltoall 增加：
@@ -95,4 +104,4 @@ op_env:
 1. PXN 在当前拓扑下对 8 卡 alltoall 有负面影响，禁用后有约 `22-24%` 提升。
 2. 禁用 PXN 可以修复 rail 分布不均衡，但无法打满每条 400G rail。
 3. 禁用 PXN 后仍只有 PDF 目标的一半左右，剩余差距不是单一 NCCL 环境变量可以补齐。
-4. 后续重点仍应放在 NCCL net plugin/SHARP、交换网络策略、credit/拥塞等待和 NCCL internal alltoall 实现效率。
+4. 后续重点仍应放在 NCCL net plugin/SHARP、交换网络策略和 NCCL internal alltoall 实现效率；`port_xmit_wait` 需要结合 allreduce 对照解读，不能单独作为 alltoall 根因。

reports_multinode_nccl_counter_probe_20260523.md

@@ -16,7 +16,7 @@
 
 补充测试显示，`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 通信模式效率问题。
+进一步抓 `counters`/`hw_counters` 后，未看到 discard、CRC/符号错误、packet sequence error、RoCE retrans、slow restart 等错误类计数增长；只看到部分端口 `port_xmit_wait` 增长。对照 allreduce 后发现，allreduce 在 `354 GB/s busbw` 时也会出现同类 `port_xmit_wait`，因此 `port_xmit_wait` 不是 alltoall 低吞吐的充分解释，只能说明发送侧存在等待。剩余问题更像 NCCL internal alltoall 通信模式、交换网络调度/拥塞控制、或缺少 NCCL net plugin/SHARP 能力。
 
 ## 裸 RDMA 4 rail 并发
 
@@ -62,6 +62,40 @@ busbw = algbw * 2 * (nranks - 1) / nranks
 
 当前 `189.12 GB/s algbw` 已接近 `4 x 400Gb/s = 200 GB/s` 理论单向总带宽。
 
+### allreduce counter 对照
+
+对同样 2 nodes x 8 GPUs、同样 4 条 HCA 的 16G allreduce 复测 counter：
+
+| Metric | Value |
+|--------|-------|
+| `algbw` | `189.22 / 188.77 GB/s` |
+| `busbw` | `354.79 / 353.94 GB/s` |
+| `Avg bus bandwidth` | `354.366 GB/s` |
+
+流量分布：
+
+| Host | HCA | Xmit GiB | Recv GiB |
+|------|-----|----------|----------|
+| aikubeworker0012 | `mlx5_0` | `178.07` | `178.03` |
+| aikubeworker0012 | `mlx5_1` | `178.07` | `178.07` |
+| aikubeworker0012 | `mlx5_6` | `178.07` | `178.03` |
+| aikubeworker0012 | `mlx5_7` | `178.07` | `178.07` |
+| aikubeworker0016 | `mlx5_0` | `178.03` | `178.07` |
+| aikubeworker0016 | `mlx5_1` | `178.07` | `178.07` |
+| aikubeworker0016 | `mlx5_6` | `178.03` | `178.07` |
+| aikubeworker0016 | `mlx5_7` | `178.07` | `178.07` |
+
+错误类 counter 增量同样为 `0`，非零等待类 counter 为：
+
+| Host | HCA | `port_xmit_wait` delta |
+|------|-----|------------------------|
+| aikubeworker0012 | `mlx5_1` | `6,555,518` |
+| aikubeworker0012 | `mlx5_7` | `6,325,059` |
+| aikubeworker0016 | `mlx5_1` | `6,585,965` |
+| aikubeworker0016 | `mlx5_7` | `6,112,874` |
+
+判断：allreduce 在达到当前 4 x 400G rail 物理上限附近时也会出现 `port_xmit_wait`，所以这个 counter 不能单独解释 alltoall 只有 `36-37 GB/s`。alltoall 的问题更偏向通信模式效率或网络调度策略，而不是简单链路错误。
+
 ## 8 卡 alltoall
 
 NCCL 输出：
@@ -163,13 +197,13 @@ NCCL 输出：
 | aikubeworker0016 | `mlx5_1` | `20,428,901` |
 | aikubeworker0016 | `mlx5_7` | `15,650,027` |
 
-判断：PXN disabled 后 alltoall 没有明显链路错误、重传或丢包证据；剩余性能缺口更偏向 `port_xmit_wait` 指向的发送等待/信用等待、交换网络拥塞控制/调度，或 NCCL internal alltoall 在当前拓扑下的通信模式效率。
+判断：PXN disabled 后 alltoall 没有明显链路错误、重传或丢包证据。结合 allreduce 对照，`port_xmit_wait` 只能作为发送等待信号，不能单独解释 alltoall 低吞吐；剩余性能缺口更偏向 NCCL internal alltoall 在当前拓扑下的通信模式效率、交换网络调度/拥塞控制，或外部 NCCL net plugin/SHARP 缺失。
 
 ## 判断
 
 1. 裸 RDMA 4 rail 可以并发跑到约 `184.62 GB/s`，网络基础带宽不是单 rail 瓶颈。
 2. 8 卡 allreduce 当前不是软件参数小调能解决的问题，性能已经贴近当前 4 条 400G rail 的物理带宽上限。
-3. 8 卡 alltoall 仍明显异常，且不是 HCA 顺序问题；PXN disabled 后 rail 已均衡，但仍出现 `port_xmit_wait`，需要继续从网络拥塞/信用等待、交换机侧策略、NCCL alltoall 模式、NCCL net plugin/SHARP 排查。
+3. 8 卡 alltoall 仍明显异常，且不是 HCA 顺序问题；PXN disabled 后 rail 已均衡，`port_xmit_wait` 不是 alltoall 独有，需要继续从 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，需要先补齐对应运行环境。

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`。复测端口 counter 后，PXN disabled 下 4 条 rail 的流量已均衡，且没有明显链路错误、丢包、RoCE 重传或 slow restart；只在部分端口看到 `port_xmit_wait` 增长，剩余差距更像发送等待/信用等待、交换网络策略或 NCCL internal alltoall 通信模式效率问题。
+进一步 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` 在高吞吐 allreduce 中也会出现，因此它不是 alltoall 低吞吐的充分解释。剩余差距更像 NCCL internal alltoall 通信模式效率、交换网络策略，或缺少 NCCL net plugin/SHARP 能力。
 
 同时，`nccl-gpu-2` 的 SSH 入口曾因未认证连接过多触发 `MaxStartups` 随机拒绝，导致 `mpirun` 拉起远端 rank 失败。已经做了临时 SSHD 缓解并拿到有效的 2 节点 x 8 GPU allreduce/alltoall 报告。
 
@@ -36,7 +36,8 @@
 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`。
+15. 对 PXN disabled 后的 8 卡 alltoall 抓取 `counters`/`hw_counters` 增量，确认 rail 已均衡且无明显错误/重传。
+16. 对同样 2x8 allreduce 抓 counter 对照，确认高吞吐 allreduce 也会出现 `port_xmit_wait`，因此该 counter 不是 alltoall 低吞吐的唯一根因。
 
 ## 关键证据
 
@@ -307,6 +308,17 @@ PXN disabled 计数器显示该参数确实修复了 rail 分布：
 
 判断：当前没有明显坏链路、丢包或重传证据；`port_xmit_wait` 更像发送侧等待 credit/拥塞控制/交换侧调度，或者 NCCL internal alltoall 在当前拓扑下没有把 rail 吞吐打起来。
 
+同样 2 nodes x 8 GPUs、同样 4 条 HCA 的 16G allreduce 对照：
+
+| 观察项 | 结果 |
+|--------|------|
+| allreduce `Avg bus bandwidth` | `354.366 GB/s` |
+| 每条 HCA 流量 | 约 `178.03-178.07 GiB`，四条 rail 均衡 |
+| 错误/重传类 counter | `0` 增量 |
+| `port_xmit_wait` | `mlx5_1`、`mlx5_7` 有增长，约 `6.11M-6.59M` |
+
+判断：allreduce 在接近物理上限时也会出现 `port_xmit_wait`，所以 alltoall 的核心问题不能只归因于该 counter。现在更应关注 NCCL alltoall 通信模式、交换网络策略、以及 NCCL net plugin/SHARP 能力差异。
+
 ### 8. 8 卡链路计数器与物理上限判断
 
 计数器探测报告：`reports_multinode_nccl_counter_probe_20260523.md`
@@ -407,7 +419,8 @@ libnccl-dev
 - 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`
+- PXN disabled 复测没有看到 discard、链路错误、RoCE 重传、slow restart、packet sequence error 等错误类 counter 增长
+- allreduce 对照同样出现 `port_xmit_wait` 但能跑到 `354.366 GB/s`，说明 `port_xmit_wait` 不是 alltoall 低吞吐的唯一根因
 
 ### 阻塞 3：`nccl-gpu-2` SSH 存在外部连接压力
 
@@ -428,9 +441,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、交换机端口速率、路由、credit/拥塞等待与交换机侧队列计数，解释 PXN disabled 后 `port_xmit_wait` 增长但无错误/重传的原因。
+7. 核对跨 Leaf 链路的 rail mapping、交换机端口速率、路由、credit/拥塞等待与交换机侧队列计数；同时用 allreduce 对照避免把 `port_xmit_wait` 误判为 alltoall 独有根因。
 8. 确认当前 PDF 的 `491.84/76.54 GB/s` 是否要求当前这两台节点在只有 4 条 400G rail 的形态下也达到；如果要求一致，需要网络/硬件侧继续介入。
-9. 对 8 卡 alltoall，重点查交换机 ECMP/自适应路由、拥塞/credit 等待、SHARP/NCCL net plugin 和 NCCL internal alltoall 行为；`NCCL_IB_HCA` 顺序与 rail 分布本身已经不是当前主问题。
+9. 对 8 卡 alltoall，重点查 SHARP/NCCL net plugin、NCCL internal alltoall 行为、交换机 ECMP/自适应路由和拥塞/credit 等待；`NCCL_IB_HCA` 顺序与 rail 分布本身已经不是当前主问题。
 
 ## 当前可交付物