解决什么问题
Qbv 学到这里，必须区分机制和排表。标准告诉设备如何按 GCL 开关 gate，但不会替你决定每条流应该走哪条路径、每一跳窗口放在哪里、多个关键流冲突时谁先谁后。
本节解决的是可行性问题。一个网络支持 Qbv，不等于任意一组流都能被调度成功。
背景与直觉
排 Qbv schedule 像给很多列车安排单线铁路。每列车有出发点、终点、运行时间和到达限制；同一段轨道同一时间不能被两列车占用；某些列车还要优先。规则清楚，不代表排表容易。
TSN 里，链路窗口就是轨道，关键流就是列车，deadline 和周期就是约束。流越多，路径越复杂，窗口越难安排。
怎么解决
判断 schedule 可行性至少需要这些输入：拓扑、链路速率、每条流的周期、最大帧长、deadline、路径、队列映射、同步误差、设备执行误差、guard band、抢占支持和已有背景流量。
| 约束 | 会限制什么 | 缺失时的风险 |
|---|---|---|
| 链路速率和帧长 | 发送时间 | 窗口过窄 |
| 流周期和 deadline | cycle 与相位 | 错过业务边界 |
| 路径 | 每跳窗口接力 | 只验证第一跳 |
| guard band | 普通帧阻塞 | 跨窗冲突 |
| 设备能力 | 队列数、GCL 长度、抢占 | 纸面可行，设备不可用 |
很多调度算法会用启发式、约束求解或增量规划。学习时不必马上掌握算法细节，但要知道：调度结果必须来自完整输入，并且要通过验证确认设备实际执行。
带来了什么新问题
可行性会随着规模急剧变难。新增一条流可能占用多个端口窗口，导致已有流相位要调整；路径选择会影响调度，调度结果又反过来影响路径选择；设备能力差异会让理论方案无法落地。
这也是 Qcc 和验证章节重要的原因。前者提供集中式配置视角，后者要求证明调度结果真的在设备上生效。
检查点
- 一个 Qbv 排表工具如果不需要最大帧长和同步误差，你会质疑什么？
- 为什么两条单独可行的关键流，合在同一链路上可能变得不可行？