learn
流量模型与 flow set：排表前先把输入说清楚
理解 Qbv 排表需要准确的周期、帧长、deadline、路径和优先级输入，flow set 描述不清会让调度结论失效。
第五章：时间感知调度核心机制IEEE 802.1QbvTAS20 分钟
本节学习目标
- 理解 Qbv 排表输入必须来自明确的 flow set。
- 知道周期、帧长、deadline 和路径缺失会怎样破坏调度。
- 能把业务需求转成调度工具需要的字段。
建议先读
核心概念
flow setperioddeadlinemaximum frame sizeroute
本章目录
- 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。但真正困难的部分在输入。如果 flow set 没有说清楚，排出来的表就没有可信基础。
一条流的平均带宽不够。你必须知道它什么时候发、每次最大多大、多久必须到、走哪条路径、进入哪个队列、是否有冗余副本。
背景与直觉
排火车时不能只知道“今天大概有 1000 名乘客”。你需要列车班次、长度、出发站、到达站、到站时间限制和轨道。Qbv 的 flow set 也是这种输入。
怎么解决
一个基础 flow set 可以包含这些字段。
| 字段 | 作用 | 缺失风险 |
|---|---|---|
| talker/listener | 定义通信端点 | 不知道保护对象 |
| period | 决定周期和重复频率 | cycle 难以选择 |
| max frame size | 决定发送时间 | 窗口宽度错误 |
| deadline | 定义边界 | 无法判断是否成功 |
| route | 决定每跳窗口 | 只验证局部 |
| traffic class | 决定 gate 控制对象 | 进入错误队列 |
| sync/error budget | 决定余量 | 纸面窗口过窄 |
Qcc 的 stream contract 和 Qbv 的 flow set 之间有强关联：前者从配置视角描述流，后者从排表视角使用这些字段。
带来了什么新问题
流量模型常常和真实业务不完全一致。应用升级后帧长变大，采样周期变化，路径改了，背景流量增加，原来的 GCL 就可能不再可靠。
因此，flow set 应该进入版本管理和验证报告。没有输入版本，就无法解释调度结果为什么成立或为什么失效。
检查点
- 一条 Qbv 关键流如果只给平均带宽，不给最大帧长和周期，排表会缺少哪些信息？
- 为什么 route 不是 GCL 之后的附属信息，而是排表前的核心输入？
掌握检查
读完本节后，先用下面这些问题校准自己，而不是只确认“看过了”。
- 1能列出一条 Qbv flow 至少需要哪些字段。
- 2能解释最大帧长错误为什么会让窗口宽度不可靠。