解决什么问题
学会 GCL 后，下一步要面对 Qbv 的真正难点：单台设备窗口正确，不等于整条路径正确。关键帧从 talker 到 listener 可能经过多台 bridge，每一跳都要在合适时间打开对应队列。如果某一跳窗口错位，报文就会等待下一个周期，甚至错过截止时间。
guard band 解决的是另一个问题：普通大帧不能跨进关键窗口。为了避免这种情况，关键窗口前需要预留一段不发送普通帧的安全时间。guard band 太小会有风险，太大则浪费链路。
背景与直觉
把多跳 Qbv 想成接力赛。第一棒不能只顾自己准时出发，还要让第二棒在合适位置接住。每一棒之间有传播时间和处理时间。如果第二棒窗口太早，报文还没到；窗口太晚，端到端延迟增加；窗口太窄，误差会吞掉余量。
guard band 像赛道清场。关键选手要通过前，普通车辆不能刚好堵在赛道上。清场时间越长越安全，但赛道利用率越低。
怎么解决
端到端调度通常要同时考虑路径、每跳发送时间、传播时间、处理时间、时钟误差和窗口长度。对周期流来说，还要保证不同周期的实例不会互相冲突。多条关键流共享链路时，问题会迅速变成复杂的组合优化。
降低 guard band 的常见方法是使用帧抢占，让普通大帧最多阻塞一个片段，而不是完整帧长。另一种方法是更精细地规划普通流量窗口，但这会增加配置复杂度。
| 问题 | 需要考虑的量 |
|---|---|
| 关键帧什么时候到下一跳 | 上一跳发送时间、传播、处理、同步误差 |
| 普通帧会不会跨窗 | 最大普通帧、链路速率、是否抢占 |
| 多条关键流是否冲突 | 周期、offset、路径共享链路 |
| 普通流量是否被饿死 | 非关键窗口剩余时间、整形策略 |
带来了什么新问题
端到端调度对输入非常敏感。流量周期稍有变化，路径调整，设备时钟质量下降，都会影响原有 GCL。集中式规划可以减少人工失配，但也需要准确拓扑和设备能力信息。
此外，优化目标之间会冲突。你可能想降低关键流延迟，同时提高链路利用率，还要保留普通流量体验和故障冗余。多目标设计正是从这些冲突出发。很多 TSN 调度论文并不是在重复标准，而是在研究这些组合约束如何求解。
检查点
- 为什么多跳 Qbv 不能简单复制同一份窗口配置到每台交换机？
- guard band 为什么既是安全余量，也是链路利用率成本？
- 如果启用帧抢占，guard band 预算会发生什么变化？