ECN 阈值过高，队列可能在发送端降速前已经接近缓冲上限，最终触发 PFC 或丢包；阈值过低，则短暂微突发也会被大量标记，发送端频繁收缩，链路利用和完成时间下降。只看“有 CNP”或“没有 PFC”无法判断参数好坏，因为相同计数可能来自不同持续时间、队列深度和流量规模。
调优要把交换队列、ECN 标记、CNP、发送速率与应用流完成时间放进同一时间线。先以官方建议和平台默认建立基线，再根据端口速率、RTT、缓冲预算和典型流量逐级调整。每次只改一个参数域，并保存主机拥塞控制版本；网卡算法或固件变化后，旧阈值不能直接沿用。
用缓冲预算确定候选范围
记录 ASIC 缓冲结构、端口速率、优先级队列、共享/专用池和无损边界，估算反馈往返期间可能继续进入的数据量。候选阈值要给控制反应留下空间，也要容纳可接受微突发。不能将不同速率端口统一为一个未换算的字节或单元值。
流量矩阵覆盖同步与背景流
分别测试单流、多对一 incast、AllReduce、长短流混合和多个作业并发，固定连接与消息分布。空载微基准无法代表同步突发。记录每个队列而非整端口总量，避免其他优先级掩盖目标 RoCE 队列。
时间线解释标记与降速
高频采集队列深度/水位、ECN 标记、CNP、发送速率、PFC 和丢弃，与作业 step 或流完成时间对齐。判断标记后队列是否及时回落、是否出现振荡，以及 PFC 是否在反馈生效前触发。累计值只用于长期趋势。
逐级调整并设置停止条件
围绕基线小步改变阈值或概率区间，每轮使用相同流量和预热，至少重复多次。出现不可纠正错误、持续 PFC、吞吐崩塌或尾延迟明显恶化立即回退。不要同时改变主机 DCQCN、PFC 和队列池，否则无法归因。
生产放量监控业务结果
先在有限机架或队列放量，持续比较训练 step、流完成、推理 P99、队列和 PFC。维护窗口后自动核对配置一致性。流量规模、网卡固件或交换软件变化触发复测，参数不作为对未来规模的性能承诺。
可执行的验收动作
- 记录 ASIC 缓冲、端口速率、RTT、队列和主机算法。
- 覆盖 incast、集合通信、长短流与多作业并发。
- 对齐队列、ECN、CNP、速率、PFC、丢弃和业务时序。
- 单因素小步调整并定义错误、PFC、时延停止条件。
- 按机架放量并在规模、固件或软件变化后复测。
当前能力如何确认
NVIDIA Cumulus Linux 文档提供 RoCE、ECN、PFC 与缓冲配置相关说明。
阈值和拥塞行为与 ASIC、端口速率、缓冲、主机算法、RTT、流量及软件版本有关。
文中机制与配置边界依据NVIDIA Cumulus RoCE 文档的当前版本核对；官方说明用于确定候选条件，实际部署仍需结合完整料号、服务器支持清单、软件组合与现场测试。
从验证结论进入交付
中科新远是 NVIDIA Networking Elite 合作伙伴。中科新远可结合 Spectrum-X、SuperNIC/ConnectX 与真实 AI 流量协助建立队列时序和分批参数实验，所有结果绑定实际平台组合。具体合作范围和项目交付内容以当前有效资质、官方目录及书面确认结果为准。
PFC 计数为零，是否说明 ECN 阈值已经最佳？
不说明。阈值可能过早导致过度降速，也可能测试未形成压力；还要看队列回落、标记、发送速率和业务尾延迟。
WeChat
Profile