解决什么问题
Qbv 的窗口不是只看长度，还要看从什么时候开始。两台交换机都配置了 100 us 关键窗口，但如果窗口相位不对，前一跳刚发出的关键帧到达后一跳时，后一跳的窗口可能已经关闭。
本节解决的是窗口相位问题。单台设备 GCL 正确，只能说明这台设备按自己的表开关 gate；端到端正确，还要让每一跳窗口在共同时间上接力。
背景与直觉
想象一条多路口绿波。每个路口绿灯长度都一样并不够，绿灯开始时间必须根据车辆到达时间错开。如果所有路口同时绿，第一辆车离开第一个路口，到第二个路口时可能已经遇到红灯。
Qbv 的 base time 和 offset 就是在共同时间上安排这种相位关系。
怎么解决
base time 定义调度表从哪个共同时间点开始，cycle 定义表多久重复一次，offset 则描述某个窗口相对周期起点的位置。设计多跳路径时，可以从 talker 的发送窗口开始，逐跳加上发送时间、传播延迟、交换处理、同步误差和执行误差。
| 项 | 作用 | 设计时要问 |
|---|---|---|
| base time | 调度表开始生效的共同时间 | 所有设备是否使用同一时间域 |
| cycle time | GCL 重复周期 | 是否匹配流周期或其公倍数 |
| window offset | 窗口在周期内的位置 | 是否接住前一跳到达 |
| window width | gate 打开的持续时间 | 是否覆盖发送和误差预算 |
一个简化设计是：第一跳窗口从 100 us 开始，关键帧发送需要 5 us，链路和处理预计 20 us，加上 10 us 误差余量，那么第二跳窗口不应该也从 100 us 开始，而应围绕大约 125 us 之后的位置设计。
带来了什么新问题
offset 设计会让调度从单点配置变成路径问题。路径一变，窗口相位可能要重算；设备处理延迟不确定，余量要增加；同步误差变大，窗口要变宽或风险上升。
此外，base time 更新本身也要小心。如果不同设备在不同时间应用新表，短时间内可能出现旧表和新表混用，导致关键帧错过窗口。
检查点
- 为什么所有设备使用相同 GCL 周期，仍然可能端到端失败？
- 设计第二跳窗口 offset 时，至少要考虑前一跳发送时间、路径延迟和哪些误差？