解决什么问题
优先级只能决定谁更应该先发，却不能指定“什么时候发”。Qbv 解决的是把关键队列的发送机会绑定到共同时间上，让关键流量在预先安排的窗口内通过，而不是在运行时和普通流量抢机会。
GCL 是这个机制的核心。它列出一组按时间执行的 gate 状态：在某个时间片里，哪些队列打开，哪些队列关闭。周期结束后，这组状态重复执行。
背景与直觉
你可以把每个队列看成一道门。门开时，队列里的帧可以竞争发送；门关时，即使队列里有帧，也不能从这个端口发出去。Qbv 的特别之处是这些门不是临时决定，而是按共同时间表周期性开关。
cycle 是时间表的重复周期，base time 是时间表从哪个共同时间开始生效，window 是某个 gate 状态持续的时间片，gate state 表示每个队列在这个时间片里开还是关。掌握这几个词，就能读懂大多数 Qbv 入门图。
怎么解决
设计一个简单 GCL 时，通常先知道关键流的周期和截止时间，再为关键队列安排窗口。窗口要足够容纳报文发送时间、同步误差、设备执行误差和 guard band。普通流量则被安排到其他时间片，避免在关键窗口内竞争。
例如一条 1ms 周期控制流需要每周期发送一次，你可以设计一个 1ms cycle，在每个 cycle 的前 100us 打开关键队列，其余时间留给普通队列。但这个 100us 不是凭感觉来的，它应该来自前面学过的预算：发送时间、同步不确定性、gate 执行误差、guard band 和设计余量。
| GCL 概念 | 问题 | 常见错误 |
|---|---|---|
| base time | 从哪个共同时间开始执行 | 没考虑设备时间同步状态 |
| cycle time | 时间表多久重复一次 | 和流周期不匹配 |
| window | 某个 gate 状态持续多久 | 只覆盖发送时间，没覆盖误差 |
| gate state | 哪些队列 open/closed | 关键流进错队列 |
本节的 GCL 编辑器允许你调节周期、关键窗口和误差。它不是完整调度器，但能直观看到窗口余量如何变化：周期越长，窗口位置和等待可能变化；窗口越窄，误差越危险；误差越大，命中判断越脆弱。
带来了什么新问题
Qbv 把运行时竞争减少了，却把复杂度前移到设计时。你必须知道流量周期、帧长、路径、设备能力和时间同步质量。流量一旦变化，原来的 GCL 可能不再可行。多个关键流共享路径时，窗口之间还会互相挤压。
另一个问题是普通流量体验。关键窗口越多，普通流量可用时间越少。如果配置过度保守，链路利用率会下降，非关键业务可能出现明显延迟。Qbv 不是只优化关键流，它是在共享网络里重新分配时间资源。
检查点
- 一个 GCL 里 base time、cycle time、window、gate state 分别回答什么问题？
- 如果关键窗口 80us，但预算表显示发送时间和误差合计需要 95us，这个配置为什么危险？
- 为什么单设备 GCL 正确，只是端到端调度的第一步？