智算网络排障手记：用原厂工具秒杀AllReduce训练锯齿问题

AllReduce 训练一直锯齿手把手教你用 hccn_tool 交换机命令30 分钟定位 RoCEv2 拥塞根因如果你的 AllReduce 训练出现 Step Time 锯齿、吞吐掉 30%、Wireshark 看到 PSN 重传——大概率不是网卡坏了而是拥塞控制链路出了三件套ECN 门限太晚、PFC 被迫兜底、DSCP→TC 映射不一致。这篇文章记录了一次真实的端到端排障过程从 NPU 侧的 hccn_tool 命令开始一路追到交换机侧的 PFC 帧计数、ECN 门限、队列丢包和 DiffServ 域配置。每一步都给出华为官方命令原文 真实回显格式 排障逻辑不编字段、不脑补输出。读完你会带走一套完整的 RoCEv2 拥塞排障思路先判“被暂停”还是“真丢包”7 条 NPU 侧命令 6 条交换机侧命令的官方用法一个可以直接贴在运维手册里的排障检查单0. 故障现象智算集群跑 AllReduce 大消息Step Time 从 1.2s 跳到 1.8s呈锯齿状集合通信带宽掉 ~30%抓包能看到 RoCE PSN 重传不是网卡 down、不是光模块误码、不是 QP Error 大面积崩第一直觉拥塞控制链路出问题不是“链路断了”。环境Node A0~A7Leaf1Atlas 800T A2 ×8Node B0~B7Leaf2Atlas 800T A2 ×8\ /Spine1RoCEv2 / UDP 4791DSCP 24 → TC3 → PFC pri3数据DSCP 25 → TC6 → PFC pri6CNPLeaf/SpinePFC ECNNPUDCQCN 开启1. 第一轮先判断“是真丢包还是被暂停”1.1 NPU 侧看 DCQCN 有没有开hccn_tool -i 0 -dcqcn -g statusdcqcn enable status: enabledcqcn enable alg mode: 00DCQCN。✅ 源端拥塞控制是开的。1.2 看 RoCE/MAC/PFC 统计hccn_tool -i 0 -stat -gpacket statistics:mac_rx_pfc_pkt_num:182033mac_tx_pfc_pkt_num:0mac_rx_pfc_pri3_pkt_num:182033roce_rx_cnp_pkt_num:312roce_tx_cnp_pkt_num:0roce_rx_all_pkt_num:981231roce_new_pkt_rty_num:124roce_out_of_order_num:55roce_unexpected_ack_num:38roce_rx_err_pkt_num:7读图mac_rx_pfc_pkt_num 18 万 → NPU 被对端/上行口 PFC 暂停过很多次roce_rx_cnp_pkt_num 312 → 交换机确实在标 ECNCNP 回来了roce_new_pkt_rty_num 124 → RoCE 层已经发生重传mac_tx_pfc_pkt_num0 → 本端没主动反压对端问题在上游/交换机结论不是“源端不收敛”是“ECN 标了但 PFC 还是被触发”反压从网络侧回来。2. 第二轮NPU 被 PFC 暂停了多久hccn_tool -i 0 -pfc_stat -g空闲态tx_pfc0_duration_time0.000ms...tx_pfc3_duration_time0.000ms...rx_pfc3_duration_time0.000mstx_pfc3_duration_warn_cnt: 0tx_pfc3_duration_err_cnt: 0本机异常态排障示例tx_pfc3_duration_time325.418msrx_pfc3_duration_time19.206mstx_pfc3_duration_warn_cnt: 2tx_pfc3_duration_err_cnt: 0含义Atlas A2 官方tx_pfcN_duration_time发送端因该优先级被 PFC 暂停的累计时间rx_pfcN_duration_time接收端向对端发 PFC 的累计时间tx_pfcN_duration_warn_cntwatchdog 检测周期内反压占比超告警门限次数tx_pfcN_duration_err_cnt超错误门限次数判断只有 pfc3RoCE 数据反压大TX 被暂停 325ms 在训练同步里非常致命AllReduce 必然等warn_cnt2 说明 PFC storm watchdog 已经观察到“反压时间占比异常”但还没到 err/自动关 PFC到这里已经能下结论NPU 侧症状是“被网络反压”根因在交换机/队列/映射不在 NPU 本身。3. 第三轮交换机上看“谁在发 PFC、谁在丢包”3.1 PFC 反压帧display dcb pfc interface 100GE 1/0/32Interface Queue Received(Frames) ReceivedRate(pps) DeadlockNum Transmitted(Frames) TransmittedRate(pps) RecoveryNum100GE1/0/32 3 0 - 0 190622 - 0100GE1/0/32 6 0 - 0 0 - 0数值为排障示例Leaf1 上行口向外发了 19 万个 PFC 帧​ → Leaf1 上行队列拥塞反过来暂停 Spine。再看 Leaf2 下行口display dcb pfc interface 100GE 1/0/1Interface Queue Received(Frames) ReceivedRate(pps) DeadlockNum Transmitted(Frames) TransmittedRate(pps) RecoveryNum100GE1/0/1 3 160244 - 0 0 - 0100GE1/0/1 6 45 - 0 28 - 0Node B0 的 NPU 收到 16 万 PFC 帧 → 被 Leaf2 暂停。反压链Spine 上行拥塞→ Leaf 上行队列超 XOFF→ Leaf 向 Spine 发 PFCTransmitted(Frames) 大→ Spine 向下游 Leaf 扩散反压→ Leaf 向 NPU 发 PFCNPU Received(Frames) 大→ NPU 停发 → AllReduce 等 → Step 锯齿3.2 ECN 到底标了多少display qos ecn statistics interface 100GE 1/0/32Interface ECN-marked packets100GE1/0/32 96627排障示例display qos ecn statistics interface 100GE 1/0/32 verboseInterface Queue ECN-marked packets100GE1/0/32 3 96627100GE1/0/32 6 0⚠️ 这条命令只有 ECN-marked packets没有 ECN mark pps、没有 WRED drops、没有 Tail drops。3.3 ECN 门限是不是太晚display qos ecn threshold interface 100GE 1/0/32Interface Queue Min(KB) Max(KB) Probability(%) Queue Size(KB)100GE1/0/32 3 287 293 40 305排障示例ECN High293KBQueue Size 已经 305KB → 标完 ECN 队列还在涨说明ECN 渐进区太窄287→293 只有 6KBMax 离 PFC XOFF 太近DCQCN 收到 CNP 再降速RTT 反应时间过去后队列已经撞 PFC3.4 队列有没有丢包普通模式display qos queue statistics interface 100GE 1/0/32Queue statistics info: interface 100GE1/0/32Queue CIR/PIR Passed Pass Rate Dropped Drop Rate Drop Time(% or kbps) (Packets/Bytes) (pps/bps) (Packets/Bytes) (pps/bps)3 0 99233123/... 123k/... 262013/... 520/... 2026-09-13 11:02:146 0 195356/... 152/... 0/0 -/0 -官方普通模式字段就是 Passed / Dropped / Drop Time 这种表。Queue3 Dropped 非 0 → 出向队列确实丢过包。3.5 丢在哪个芯片/哪个 VOQverbose 模式display qos queue statistics interface 100GE 1/0/32 verboseQueue Slot Chip VOQ Dropped(Packets)0 1 0 4111 01 1 0 4110 02 1 0 4109 03 1 0 4108 2620134 1 0 4107 05 1 0 4106 06 1 0 4105 07 1 0 4104 0→ 丢包集中在Queue3 / Slot1 / Chip0 / VOQ 4108正好是无损 RoCE 数据队列。4. 第四轮流有没有进错队列AI 集群高频坑for i in $(seq 0 7); do hccn_tool -i $i -dscp_to_tc -g; donedevice 0: dscp 24 - tc 3device 1: dscp 24 - tc 3device 2: dscp 24 - tc 2device 3: dscp 24 - tc 3device 4: dscp 24 - tc 3device 5: dscp 24 - tc 2device 6: dscp 24 - tc 3device 7: dscp 24 - tc 3交换机侧display diffserv domain ds1ip-dscp-inbound 24 phb af3 greenip-dscp-inbound 25 phb af4 greenAF3→TC3AF4→TC6。问题device2 / device5 把 DSCP24 映射到 TC2交换机把 RoCE 数据当 TC3 做无损这两张卡的流量进了非无损 TC2 → 不受 PFC/ECN 保护拥塞时直接丢这能解释为什么整体 ECN 在跑但还是有 Dropped(Packets)而且重传分布不均匀5. 根因排障收口层现象证据NPU被 PFC 暂停 325mstx_pfc3_duration_time325.418msNPUECN/CNP 有但重传发生roce_rx_cnp_pkt_num312、roce_new_pkt_rty_num124交换机 PFCLeaf 上行狂发 PFCTransmitted(Frames)190622交换机 ECN门限太晚Min 287 / Max 293 / Queue Size 305交换机队列Queue3 丢包普通模式 Dropped 非 0verbose VOQ 4108 Dropped 262013NPU 配置DSCP→TC 不一致device2/5 是 tc2交换机期望 tc3一句话根因ECN 门限离 PFC XOFF 太近DCQCN 降速来不及PFC 被迫兜底同时部分 NPU 的 DSCP→TC 映射错误使一部分 RoCE 流量脱离无损队列最终表现为 AllReduce 锯齿、PSN 重传、Queue3 VOQ 丢包。6. 修复动作把 ECN Max 拉到明显低于 PFC XOFF留几个 MTU 足够 DCQCN 反应时间ECN 低/高门限拉开例如 30%~70% 缓冲而不是 287/293KB 这种 6KB 窄区统一所有 NPUdscp 24 - tc 3、dscp 25 - tc 6检查 headroom / shared buffer抑制 incast 微突发PFC storm watchdog 先观察确认无抖动后再评估 mode 2 自动关 PFC用 display qos queue statistics ... verbose 持续看 VOQ 丢包是否归零7. 排障检查单【NPU】hccn_tool -i 0 -link -ghccn_tool -i 0 -stat -ghccn_tool -i 0 -dcqcn -g statushccn_tool -i 0 -pfc_stat -ghccn_tool -i 0 -pfc_storm -ghccn_tool -i 0 -dscp_to_tc -ghccn_tool -i 0 -qp_info -g【Switch】display dcb pfc interface 100GE 1/0/32display dcb pfc interface 100GE 1/0/1display qos ecn statistics interface 100GE 1/0/32display qos ecn statistics interface 100GE 1/0/32 verbosedisplay qos ecn threshold interface 100GE 1/0/32display qos queue statistics interface 100GE 1/0/32display qos queue statistics interface 100GE 1/0/32 verbosedisplay diffserv domain ds1