解决什么问题
前面几节讲了共同时间如何工作、误差从哪里来、预算如何进入 Qbv 窗口。本节回答最后一个工程问题：你怎么证明这些假设在现场真的成立？
验证共同时间不能只截一张“synchronized”的设备页面。同步状态是必要信息，但不是完整证据。你需要知道同步状态持续多久，offset 范围如何变化，grandmaster 有没有切换，holdover 时误差怎么增长，抓包时间戳来自哪里，以及关键帧是否真的命中了窗口。
应该保存哪些证据
一份更可信的调度验证报告，至少应该把时间同步证据和业务流证据放在一起。
| 证据 | 用来回答什么问题 |
|---|---|
| grandmaster 身份和时钟质量 | 参考时间源是谁，是否发生切换 |
| 各设备同步状态 | 测试期间是否 locked，是否进入 holdover |
| offset / path delay 范围 | 误差是否落在预算假设内 |
| timestamp 来源 | 是硬件时间戳、设备日志还是软件抓包 |
| Qbv 配置快照 | base time、cycle、GCL 是否和测试一致 |
| 关键帧抓包 | 帧是否在预期窗口附近到达和离开 |
| 背景负载条件 | 测试是否覆盖竞争和压力场景 |
这些证据的价值在于可复盘。出现迟到时，你可以判断是同步误差变大、窗口预算不足、普通帧跨窗、配置漂移，还是测试时间戳本身不可信。
验证不是只看平均值
TSN 的验证重点是边界。平均 offset、平均延迟、平均抖动都可能掩盖尾部风险。如果关键窗口只有几十微秒，一个短暂的同步异常就可能造成迟到，但平均值仍然漂亮。
因此，验证时要关注范围、最大值、异常段和状态变化。尤其要单独观察 grandmaster 切换、链路重连、设备重启、负载升高、温度变化等条件下的行为。很多系统在稳定状态下表现很好，在切换或 holdover 阶段才暴露风险。
怎么和后续学习连接
共同时间验证不是孤立章节。后面学习 Qbv 时，你会把同步误差放进窗口预算；学习 FRER 时，你会关心多路径时间差和消除窗口；学习测试验证时，你会把时间同步状态、流量构造和抓包证据组织成完整报告。
这也是为什么本章是后续论文阅读的前置能力。很多论文会直接写“assume synchronized clocks”或“bounded clock drift”。现在你应该知道这不是一句无害背景，而是一个会决定模型能否落地的关键假设。
带来了什么新问题
验证越认真，成本越高。你需要设备暴露足够状态，需要可靠抓包点，需要保存配置和日志，需要构造背景压力，还需要长期观察异常。对小实验来说，这些可能显得繁琐；对工业现场来说，这些正是可信结论和演示效果之间的区别。
另一个问题是证据粒度。过粗的证据无法定位问题，过细的证据又难以维护。TSNBIT 后续的验证章节会继续讨论如何设计测试计划、如何组织报告、如何判断一份论文或产品白皮书里的评估是否足够可信。
检查点
- 如果测试报告只写“设备已同步”，但没有 offset 范围和 grandmaster 信息，你还需要补什么？
- 为什么 grandmaster 切换、holdover 和链路重连要单独列为验证场景？