突发与尾延迟：平均负载为什么会骗人

解决什么问题

很多网络看监控时都很健康：平均带宽不高，平均延迟也低。但关键控制帧关心的是每个周期是否准时，不是平均值是否好看。突发流量会在很短时间内把队列填满，让少数关键帧落入尾延迟。

本节解决的是平均指标的误导。TSN 关注边界，所以必须理解为什么平均负载不能替代最坏情况分析。

背景与直觉

一条高速公路白天平均不堵，不代表某个入口在 30 秒内不会排长队。网络也一样。多个 talker 同时向一个出口汇聚时，即使每个 talker 的平均带宽都很低，短时间内仍可能超过出口发送能力。

这种短暂拥塞就是关键流最怕的场景。它不一定持续很久，却足够让某个周期的控制帧错过 deadline。

怎么解决

分析突发要从时间窗口看负载，而不是只看长时间平均。你可以问：在 100 us、1 ms、10 ms 这些窗口里，最多会有多少普通帧同时到达同一出口？关键帧在这些窗口里会不会被排到后面？

后面的 CBS 会尝试压平突发，Qbv 会把关键流放进时间窗口，验证章节会要求记录分位数、最大值和背景压力，而不只给平均值。

带来了什么新问题

一旦开始关注尾延迟，测试和建模都会变难。你需要构造足够坏的背景流量，需要运行足够长时间，需要知道流量生成器是否真的产生了突发，还要说明没有测试到的场景是否仍在结论边界内。

这也是 TSN 设计不应该只靠“现场跑了一会没问题”的原因。尾部问题可能低频出现，但对控制系统来说一次错过周期也可能不可接受。

检查点

• 为什么 10 秒平均负载不能证明 1 ms 周期控制流安全？
• 如果要测试突发风险，你会怎样设置背景流量，而不是只跑平滑吞吐？