learn
调度可行性：标准定义机制，不替你求解排表
理解 Qbv 真正困难的是多流、多跳、多约束下的可行排表，标准机制本身不会自动产生日程。
第五章：时间感知调度核心机制IEEE 802.1QbvTAS22 分钟
本节学习目标
- 理解 Qbv 标准提供 gate 机制，但排表仍是工程和算法问题。
- 知道多流、多跳、deadline、guard band 和设备能力会共同限制可行性。
- 能判断一个调度结论是否缺少输入或验证证据。
建议先读
核心概念
schedule feasibilityconstraintmulti-hop flowdeadline miss
本章目录
- 01GCL、cycle 与窗口：Qbv 的最小心智模型从 Gate Control List 的周期、base time、窗口和队列状态理解 Time-Aware Shaper。
- 02guard band 与路径接力：Qbv 真正难在端到端理解普通大帧跨窗、窗口余量、路径传播延迟和多跳接力如何影响 Qbv 可行性。
- 03base time 与 offset：窗口从什么时候开始才算对理解 Qbv 调度表里的 base time、cycle offset 和多设备窗口相位，避免每台设备都正确却端到端错位。
- 04调度可行性：标准定义机制，不替你求解排表理解 Qbv 真正困难的是多流、多跳、多约束下的可行排表，标准机制本身不会自动产生日程。
- 05流量模型与 flow set：排表前先把输入说清楚理解 Qbv 排表需要准确的周期、帧长、deadline、路径和优先级输入，flow set 描述不清会让调度结论失效。
- 06运行时更新与切换：新旧 GCL 混用会怎样出错理解 Qbv 配置变更时的 base time、版本一致性和回滚问题，避免多设备更新过程中出现短暂窗口错位。
- 07Qbv 调试信号：迟到时先看哪几类证据把 Qbv 失败拆成时间同步、队列映射、窗口相位、guard band、流量模型和设备执行几类证据，形成调试路径。
解决什么问题
Qbv 学到这里，必须区分机制和排表。标准告诉设备如何按 GCL 开关 gate，但不会替你决定每条流应该走哪条路径、每一跳窗口放在哪里、多个关键流冲突时谁先谁后。
本节解决的是可行性问题。一个网络支持 Qbv，不等于任意一组流都能被调度成功。
背景与直觉
排 Qbv schedule 像给很多列车安排单线铁路。每列车有出发点、终点、运行时间和到达限制；同一段轨道同一时间不能被两列车占用；某些列车还要优先。规则清楚，不代表排表容易。
TSN 里，链路窗口就是轨道，关键流就是列车，deadline 和周期就是约束。流越多，路径越复杂，窗口越难安排。
怎么解决
判断 schedule 可行性至少需要这些输入：拓扑、链路速率、每条流的周期、最大帧长、deadline、路径、队列映射、同步误差、设备执行误差、guard band、抢占支持和已有背景流量。
| 约束 | 会限制什么 | 缺失时的风险 |
|---|---|---|
| 链路速率和帧长 | 发送时间 | 窗口过窄 |
| 流周期和 deadline | cycle 与相位 | 错过业务边界 |
| 路径 | 每跳窗口接力 | 只验证第一跳 |
| guard band | 普通帧阻塞 | 跨窗冲突 |
| 设备能力 | 队列数、GCL 长度、抢占 | 纸面可行，设备不可用 |
很多调度算法会用启发式、约束求解或增量规划。学习时不必马上掌握算法细节，但要知道：调度结果必须来自完整输入，并且要通过验证确认设备实际执行。
带来了什么新问题
可行性会随着规模急剧变难。新增一条流可能占用多个端口窗口，导致已有流相位要调整；路径选择会影响调度，调度结果又反过来影响路径选择；设备能力差异会让理论方案无法落地。
这也是 Qcc 和验证章节重要的原因。前者提供集中式配置视角，后者要求证明调度结果真的在设备上生效。
检查点
- 一个 Qbv 排表工具如果不需要最大帧长和同步误差，你会质疑什么？
- 为什么两条单独可行的关键流，合在同一链路上可能变得不可行？
掌握检查
读完本节后，先用下面这些问题校准自己，而不是只确认“看过了”。
- 1能列出判断 Qbv schedule 是否可行所需的关键输入。
- 2能解释为什么流数量增加后排表难度会上升。