learn
base time 与 offset：窗口从什么时候开始才算对
理解 Qbv 调度表里的 base time、cycle offset 和多设备窗口相位，避免每台设备都正确却端到端错位。
第五章：时间感知调度核心机制IEEE 802.1QbvTAS20 分钟
本节学习目标
- 理解 base time 决定调度表从哪个共同时间点开始生效。
- 知道多跳路径上的窗口不能简单复制同一相位。
- 能把 offset 和路径传播、交换处理、同步误差联系起来。
建议先读
核心概念
base timecycle offsetphase alignmentpath propagation
本章目录
- 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 的窗口不是只看长度，还要看从什么时候开始。两台交换机都配置了 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 时，至少要考虑前一跳发送时间、路径延迟和哪些误差？
掌握检查
读完本节后，先用下面这些问题校准自己，而不是只确认“看过了”。
- 1能解释为什么所有设备使用同一个 cycle 仍可能窗口错位。
- 2能说明后续跳的窗口为什么通常要相对前一跳偏移。