ISSUE-016: TP=2 通信原语 G5 与 Math 延迟偏差
发现日期：2026-05-10
状态：已修复
类型：实现 bug （3 层叠加）
影响范围：所有 TP=2 通信原语 (AllReduce/AllGather/ReduceScatter) 的 G5 仿真精度
问题现象
G5 仿真 vs Math baseline 偏差不一致，且模式矛盾：
| 原语 | N | Size | Math (us) | G5 (us) | G5/Math | 方向 |
|---|---|---|---|---|---|---|
| AllReduce | 2 | 458752 | 1.964 | 1.967 | 1.00x | 匹配 |
| AllGather | 2 | 1179648 | 3.967 | 5.411 | 1.36x | G5 偏慢 |
| ReduceScatter | 2 | 1048576 | 3.603 | 4.895 | 1.36x | G5 偏慢 |
| topk AllGather | 2 | 32768 | 0.781 | 0.366 | 0.47x | G5 偏快 |
| MoE dispatch | 64 | 917504 | 5.289 | 4.785 | 0.90x | G5 偏快 |
Math baseline: T = M/(beta*u) + alpha_start = M/360000 + 0.69 us
调查过程
Bug 1: AllGather/ReduceScatter 数据量错误
- [查代码]
expand.rs:expand_one对所有原语统一调用expand_ring_steps - [查代码]
helpers.rs:60:chunk_bytes = data_bytes / (N * num_chunks) - [查 spec] CommPrimitiveSpec docstring:
msg_size_bytes = 单芯片参与本次通信的数据量 - [分析] AG/RS 的
data_bytes是 per-chip wire data，但expand_ring_steps当作全局 buffer 再除 N - [验证] AG N=2：每芯片实际发 M/2 = 589824 bytes，应发 M = 1179648 bytes
- AllReduce 碰巧正确：
2*(N-1)/N = 1for N=2，总量恰等于 M
修复：expand_one 中对 AG/RS 执行 data_bytes *= N 再进入 ring expand。
Bug 2: segment_queue HOL blocking
修复 Bug 1 后 AG/RS 从 0.74x 变为 1.36x（方向翻转，暴露第二层问题）。
- [实验] 改变 CDMA unit 数 (C=1/2/4/8)：结果完全一致 → 排除 multi-channel 竞争
- [实验] 改变 link BW (400→10000 GB/s)：结果不变 → 排除链路带宽瓶颈
- [查代码]
paxi_core.rs:take_segments: FIFO 队列遇到未就绪段就停止 - [分析] 8 个 CDMA 同时 submit，按序追加到同一 FIFO。Unit 0 的 MPS1(ready@T+64) 阻塞了 Unit 1-7 的 MPS0(ready@T)
- [查 spec] G5-PAXICore spec: "同一事务的 segment 必须按序" — 是 per-txn 约束，不是全局 FIFO
修复：take_segments 改为跳过未就绪段继续取后续已就绪段（per-txn 内序保证，跨 txn 不阻塞）。
Bug 3: LG 负载不均衡 （根因）
修复 Bug 2 后 AG 1.125MB 改善到 1.10x，但仍有 10% gap。进一步排查：
- [实验] 精确分解延迟：CDMA done@2599ns，sim@3975ns，post-CDMA=1376ns
- [计算] 理论 LG drain=748ns，实际 1376ns，差 628 ns 无法解释
- [查 DIAG] LG 发包统计：LG7=176 pkts, LG0=84 pkts （2.1× 不均衡！）
- [计算] 最忙 LG 176×21.5ns=3784ns 决定总时间，均匀 144×21.5=3096ns → 不均衡贡献 688ns ≈ 差距
- [查代码]
paxi.rs:submit中pick_least_busy_lg+try_arbitrate互相干扰 - [分析] 8 CDMA 同时 submit 时，前几个 submit 的 try_arbitrate 更新 tx_busy_until_ns，干扰后续 submit 的 LG 选择
修复：LG 分配改为纯 round-robin（不依赖 busy 状态）。
参数对齐
- [查 spec] CDMA startup 文档定义 290ns(ddr_r+ddr_w+noc+2*d2d)，config 配 200ns → 修正为 290
- [分析] Math α_start=690ns 中 2×c2c_lat=400ns 包含 SerDes/MAC/FEC 延迟
- [实验] link base_latency 从 0.025→0.200 us 对齐 Math c2c_lat
- [验证] topk AG 从 0.47x→1.03x，dispatch 从 0.91x→0.89x
CDMA pipeline 优化
- [分析] AllReduce 2-step dep chain 每步都有 CDMA startup(290ns)，Math 只计 1 次
- [查 spec] 真实 DMA 引擎对 back-to-back 指令做描述符预取，不重复 startup
- [实现] dep satisfied 且 datapath 刚释放时，跳过 startup（pipeline hit）
根因分析
三层 bug 叠加：
- 数据量层 (
expand.rs): AG/RS 的 per-chip wire data 被 expand_ring_steps 再除 N → 少发一半 - 调度层 (
paxi_core.rs)：全局 FIFO + per-MPS earliest_ready 门控 → 跨事务 HOL blocking - 负载均衡层 (
paxi.rs): pick_least_busy_lg 在并发 submit 时被 try_arbitrate 反馈干扰 → 2× LG 不均衡
层 1 让 AG/RS 偏快(0.74x)，层 2+3 让 G5 整体偏慢。原始数据中 AllReduce 恰好"1.00x"是三个 bug 互相抵消的假象。
Spec / 文档依据
CommPrimitiveSpec:
msg_size_bytes: 单芯片参与本次通信的数据量 (bytes)
G5-PAXICore 事务层设计规格：
"同一事务的 segment 必须按序提交（FIFO）" — per-txn 约束，不要求跨 txn 全局 FIFO
G5-CDMA 建模设计规格：
STARTUP_LATENCY_NS = ddr_r(150) + ddr_w(10) + noc(50) + 2*d2d(80) = 290 ns
验证文档 comm-primitive.md：
alpha_start = 2*c2c_lat + ddr_r + ddr_w + noc + 2*d2d = 0.69 usc2c_lat = 0.200 us（chip-to-chip 单向传播延迟，含 SerDes/MAC）
业界实践 (gem5/GARNET, BookSim, NS3-RDMA):
DMA BW > Link BW 时，注入门控不是瓶颈，数据视为始终就绪于 NIC buffer
解决方案
涉及文件
| 文件 | 改动 |
|---|---|
perfmodel/evaluation/g5/src/collective/expand.rs | expand_one 中 AG/RS 执行 data_bytes *= N |
perfmodel/evaluation/g5/src/tier6/paxi_core.rs | take_segments 跨 txn 不阻塞（跳过未就绪段） |
perfmodel/evaluation/g5/src/tier6/paxi.rs | LG 分配改为 round-robin |
perfmodel/evaluation/g5/src/tier6/cdma.rs | back-to-back pipeline（dep 满足时跳过 startup） |
configs/chips/SG2262.yaml | CDMA startup 200→290 ns |
docs/validation/通信原语评估-TPS186/scripts/run_eval.py | c2c_latency 0.025→0.200 us |
验证
修复后运行：
python docs/validation/通信原语评估-TPS186/scripts/run_eval.py --quick
修复前 → 修复后：
| 原语 | Math | 修复前 | 修复后 | 修复前比值 | 修复后比值 |
|---|---|---|---|---|---|
| AllReduce | 1.964 | 1.967 | 1.923 | 1.00x | 0.98x |
| AllGather | 3.967 | 5.411 | 3.898 | 1.36x | 0.98x |
| ReduceScatter | 3.603 | 4.895 | 3.799 | 1.36x | 1.05x |
| topk AG | 0.781 | 0.366 | 0.806 | 0.47x | 1.03x |
| dispatch | 5.289 | 4.785 | 4.688 | 0.90x | 0.89x |
| combine | 7.837 | 6.902 | 6.649 | 0.88x | 0.85x |
TP=2 核心原语 (AR/AG/RS/topk) 全部在 ±5% 以内。dispatch/combine 偏快是 switch latency 建模差异（交换机延迟 vs Math 的 α_switch 串行叠加），属预期行为。
遗留问题
- dispatch/combine 0.85-0.89x：可进一步对齐 switch 延迟建模，非阻塞项
- round-robin LG 分配在非对称拓扑下可能不是最优：后续如有需求可改为 weighted-RR