F
Member
一个 CRC 错误，在交换机上只是一行日志，在 TCP 层可能变成一次 200 ms 的超时重传。链路误码到应用性能之间，有一条被长期低估的放大链。这篇把这个链条拆开，讲清楚为什么"光功率正常"和"应用不卡"是两件事。
一、放大链条的四级
第 1 级：物理层误码
光链路 BER 从 1e-12 劣化到 1e-8。
在 10G 链路上，1e-8 意味着平均每 100 秒错一个比特。
单看这个数字，好像无所谓。
第 2 级：帧丢弃
一个比特错，整个以太网帧的 CRC 校验就失败，帧被丢弃。
10G 链路、1500 字节帧，1e-8 BER 下帧丢失率约 1e-4，
即每 10 万个帧丢 100 个。
如果 FEC 存在，大部分能被纠正，但 FEC 有余量上限。
第 3 级：TCP 重传与拥塞窗口
这是放大最剧烈的一级。
TCP 检测到丢包（3 个重复 ACK 或超时），会：
快速重传：拥塞窗口减半，从一个 RTT 后重发
超时重传：拥塞窗口降到 1 个 MSS，进入慢启动
超时的最小 RTO 通常是 200 ms（Linux 默认 200 ms，可调）。
也就是说，一次超时重传，这条连接至少空转 200 ms。
第 4 级：应用层可见的劣化
对推理服务：TPOT 从 30 ms 抖到 250 ms
对存储：小文件同步从 5 ms 变成 300 ms
对训练：AllReduce 的某个 rank 掉队，整个迭代等它
结论：链路误码的代价不是"丢一个包"，而是"拥塞窗口的收缩与恢复"。
二、为什么长肥管道（LFN）更惨
BDP = 带宽 × RTT
同机房 10G，RTT 0.2 ms → BDP = 250 KB
跨地域 10G，RTT 20 ms → BDP = 25 MB
在 BDP 25 MB 的链路上，拥塞窗口从 25 MB 掉到 12.5 MB，
恢复需要多个 RTT，实际业务感知是"卡了半秒到两秒"。
所以同样的 BER，跨地域链路的业务影响远大于同机房。
这也是为什么跨地域场景对光链路的要求反而更高——不只是带宽够不够。
三、怎么判断是链路误码还是拥塞
这两者的现象很像，但处理方式完全相反。
链路误码的特征：
丢包与业务量无关，空闲时也在丢
rx_crc_errors / rx_missed_errors 持续增长
重传统计里 retrans_segs 增长但 in_errors 也可能增长
换线或换端口后消失
拥塞的特征：
丢包与业务量正相关
交换机队列水位高，有 ECN 标记或 PFC pause
多台机器同时出现，且集中在上行口
排查命令（Linux）：
nstat -az | grep -E "Retrans|InCsumErrors|InErrs"
ss -ti dst <peer> 看单条连接的 cwnd、rtt、retrans
ethtool -S eth0 | grep -E "crc|drop|err"
sar -n EDEV 1 看 eth0 的 rxerr/srxdrop
一个技巧：用 ss -ti 看单条连接的 cwnd 曲线。
如果 cwnd 周期性被打到 1 或减半，且 rtt 没有明显上升，
基本可以确定是丢包（链路问题），而不是拥塞（rtt 会先上升）。
四、FEC 到底救了多少
RS(544,514) 在 25G/50G 上的纠错能力，大致能救回 1e-5 量级的原始误码。
但代价是：
引入约 100 ns 的编解码延迟（可接受）
突发错误会吃掉纠错预算，出现"FEC 后仍有错"的悬崖效应
我们的经验阈值：
FEC 前 BER < 1e-9 → 链路干净
1e-9 ~ 1e-7 → 可运行，但要列入巡检，趋势看增长
> 1e-7 → 会有业务影响，必须处理
注意要用"FEC 前后的差值"来判断物理层质量，而不是只看 FEC 后为 0。
FEC 后为 0 只是说明纠错在起作用，不代表链路健康。
五、四个具体动作
1) 把误码计数纳入监控
采集周期 10 秒，保留 30 天。只看当前值没有意义，要看增长率。
2) 建立 DOM 基线
新装时记录一次温度/光功率/偏置电流，之后按周对比。
偏置电流缓慢上升是激光器老化的最早信号。
3) 端面清洁作为标准动作
现场数据：高速链路故障里一半以上与端面污染有关。
每次插拔前清洁，成本几乎为零。
4) 跨地域链路单独设阈值
RTT 高的链路，同样的 BER 造成的业务影响更大，阈值要更严。
六、一个反直觉的结论
很多团队花大量精力调 TCP 参数（扩大窗口、开 BBR），
但根因是链路在丢包。BBR 在丢包链路上表现确实比 CUBIC 好，
但它只是绕开了拥塞控制的保守策略，物理层的误码并没有消失，
而且 BBR 的探测机制会在高误码链路上产生额外流量。
先修物理层，再调协议栈。顺序反了，调参永远调不完。
—— 北亿纤通（F-tone Networks）光互联技术团队
技术资料：https://www.f-tone.com
一、放大链条的四级
第 1 级：物理层误码
光链路 BER 从 1e-12 劣化到 1e-8。
在 10G 链路上，1e-8 意味着平均每 100 秒错一个比特。
单看这个数字，好像无所谓。
第 2 级：帧丢弃
一个比特错，整个以太网帧的 CRC 校验就失败，帧被丢弃。
10G 链路、1500 字节帧，1e-8 BER 下帧丢失率约 1e-4，
即每 10 万个帧丢 100 个。
如果 FEC 存在，大部分能被纠正，但 FEC 有余量上限。
第 3 级：TCP 重传与拥塞窗口
这是放大最剧烈的一级。
TCP 检测到丢包（3 个重复 ACK 或超时），会：
快速重传：拥塞窗口减半，从一个 RTT 后重发
超时重传：拥塞窗口降到 1 个 MSS，进入慢启动
超时的最小 RTO 通常是 200 ms（Linux 默认 200 ms，可调）。
也就是说，一次超时重传，这条连接至少空转 200 ms。
第 4 级：应用层可见的劣化
对推理服务：TPOT 从 30 ms 抖到 250 ms
对存储：小文件同步从 5 ms 变成 300 ms
对训练：AllReduce 的某个 rank 掉队，整个迭代等它
结论：链路误码的代价不是"丢一个包"，而是"拥塞窗口的收缩与恢复"。
二、为什么长肥管道（LFN）更惨
BDP = 带宽 × RTT
同机房 10G，RTT 0.2 ms → BDP = 250 KB
跨地域 10G，RTT 20 ms → BDP = 25 MB
在 BDP 25 MB 的链路上，拥塞窗口从 25 MB 掉到 12.5 MB，
恢复需要多个 RTT，实际业务感知是"卡了半秒到两秒"。
所以同样的 BER，跨地域链路的业务影响远大于同机房。
这也是为什么跨地域场景对光链路的要求反而更高——不只是带宽够不够。
三、怎么判断是链路误码还是拥塞
这两者的现象很像，但处理方式完全相反。
链路误码的特征：
丢包与业务量无关，空闲时也在丢
rx_crc_errors / rx_missed_errors 持续增长
重传统计里 retrans_segs 增长但 in_errors 也可能增长
换线或换端口后消失
拥塞的特征：
丢包与业务量正相关
交换机队列水位高，有 ECN 标记或 PFC pause
多台机器同时出现，且集中在上行口
排查命令（Linux）：
nstat -az | grep -E "Retrans|InCsumErrors|InErrs"
ss -ti dst <peer> 看单条连接的 cwnd、rtt、retrans
ethtool -S eth0 | grep -E "crc|drop|err"
sar -n EDEV 1 看 eth0 的 rxerr/srxdrop
一个技巧：用 ss -ti 看单条连接的 cwnd 曲线。
如果 cwnd 周期性被打到 1 或减半，且 rtt 没有明显上升，
基本可以确定是丢包（链路问题），而不是拥塞（rtt 会先上升）。
四、FEC 到底救了多少
RS(544,514) 在 25G/50G 上的纠错能力，大致能救回 1e-5 量级的原始误码。
但代价是：
引入约 100 ns 的编解码延迟（可接受）
突发错误会吃掉纠错预算，出现"FEC 后仍有错"的悬崖效应
我们的经验阈值：
FEC 前 BER < 1e-9 → 链路干净
1e-9 ~ 1e-7 → 可运行，但要列入巡检，趋势看增长
> 1e-7 → 会有业务影响，必须处理
注意要用"FEC 前后的差值"来判断物理层质量，而不是只看 FEC 后为 0。
FEC 后为 0 只是说明纠错在起作用，不代表链路健康。
五、四个具体动作
1) 把误码计数纳入监控
采集周期 10 秒，保留 30 天。只看当前值没有意义，要看增长率。
2) 建立 DOM 基线
新装时记录一次温度/光功率/偏置电流，之后按周对比。
偏置电流缓慢上升是激光器老化的最早信号。
3) 端面清洁作为标准动作
现场数据：高速链路故障里一半以上与端面污染有关。
每次插拔前清洁，成本几乎为零。
4) 跨地域链路单独设阈值
RTT 高的链路，同样的 BER 造成的业务影响更大，阈值要更严。
六、一个反直觉的结论
很多团队花大量精力调 TCP 参数（扩大窗口、开 BBR），
但根因是链路在丢包。BBR 在丢包链路上表现确实比 CUBIC 好，
但它只是绕开了拥塞控制的保守策略，物理层的误码并没有消失，
而且 BBR 的探测机制会在高误码链路上产生额外流量。
先修物理层，再调协议栈。顺序反了，调参永远调不完。
—— 北亿纤通（F-tone Networks）光互联技术团队
技术资料：https://www.f-tone.com