learn
Qbv 调试信号：迟到时先看哪几类证据
把 Qbv 失败拆成时间同步、队列映射、窗口相位、guard band、流量模型和设备执行几类证据，形成调试路径。
第五章：时间感知调度核心机制IEEE 802.1QbvTAS22 分钟
本节学习目标
- 能把 Qbv 迟到问题拆成几类可检查证据。
- 知道调试不应只盯 GCL 文本，还要看时间、队列和流量输入。
- 能设计基础排查顺序。
建议先读
核心概念
window missqueue mappingtime sync evidenceguard band
本章目录
- 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、流量模型和设备执行几类证据，形成调试路径。
解决什么问题
关键帧迟到时，很多人第一反应是“GCL 写错了”。这可能对，但不一定。Qbv 依赖共同时间、队列映射、流量模型、窗口相位、guard band 和设备执行，任何一环错都会表现成迟到。
本节解决调试路径问题：把一个失败现象拆成可验证的证据，而不是凭直觉改表。
背景与直觉
Qbv 像一套精密接力。接力失败可能是第一棒出发晚了，也可能是第二棒站错位置，可能是赛道被占，也可能是计时器不一致。只看终点迟到无法定位。
怎么解决
可以按下面顺序检查。
| 检查项 | 典型证据 |
|---|---|
| gPTP 状态 | offset、同步状态、grandmaster、时间域 |
| 队列映射 | PCP/流标识是否进入受控队列 |
| GCL 相位 | base time、cycle、offset 是否接力 |
| guard band | 普通大帧是否跨窗阻塞 |
| 流量模型 | 帧长、周期、突发是否超规格 |
| 设备执行 | 配置版本、应用状态、计数器 |
| 抓包时间戳 | tx/rx 时间和窗口命中情况 |
调试时要尽量保留原始数据。改一次配置就覆盖旧状态，会让问题变得不可复盘。
带来了什么新问题
Qbv 调试往往需要跨设备证据。单点抓包可能只看到结果，看不到前一跳已经错过窗口；设备计数器可能粒度不够；时间戳精度可能不足。
因此，Qbv 调试和验证章强相关。没有可观测性计划，调试很容易变成反复试错。
检查点
- 如果关键帧在第二跳迟到，你会先检查第二跳 GCL，还是也要检查第一跳发送时间？为什么？
- 为什么队列映射错误会让看起来正确的 GCL 完全不起作用？
掌握检查
读完本节后，先用下面这些问题校准自己，而不是只确认“看过了”。
- 1能列出 Qbv 关键帧迟到时最先检查的五类证据。
- 2能解释为什么抓包显示迟到后还要回查队列映射和 gPTP 状态。