验证共同时间：从同步状态到调度证据

解决什么问题

前面几节讲了共同时间如何工作、误差从哪里来、预算如何进入 Qbv 窗口。本节回答最后一个工程问题：你怎么证明这些假设在现场真的成立？

验证共同时间不能只截一张“synchronized”的设备页面。同步状态是必要信息，但不是完整证据。你需要知道同步状态持续多久，offset 范围如何变化，grandmaster 有没有切换，holdover 时误差怎么增长，抓包时间戳来自哪里，以及关键帧是否真的命中了窗口。

应该保存哪些证据

一份更可信的调度验证报告，至少应该把时间同步证据和业务流证据放在一起。

这些证据的价值在于可复盘。出现迟到时，你可以判断是同步误差变大、窗口预算不足、普通帧跨窗、配置漂移，还是测试时间戳本身不可信。

验证不是只看平均值

TSN 的验证重点是边界。平均 offset、平均延迟、平均抖动都可能掩盖尾部风险。如果关键窗口只有几十微秒，一个短暂的同步异常就可能造成迟到，但平均值仍然漂亮。

因此，验证时要关注范围、最大值、异常段和状态变化。尤其要单独观察 grandmaster 切换、链路重连、设备重启、负载升高、温度变化等条件下的行为。很多系统在稳定状态下表现很好，在切换或 holdover 阶段才暴露风险。

怎么和后续学习连接

共同时间验证不是孤立章节。后面学习 Qbv 时，你会把同步误差放进窗口预算；学习 FRER 时，你会关心多路径时间差和消除窗口；学习测试验证时，你会把时间同步状态、流量构造和抓包证据组织成完整报告。

这也是为什么本章是后续论文阅读的前置能力。很多论文会直接写“assume synchronized clocks”或“bounded clock drift”。现在你应该知道这不是一句无害背景，而是一个会决定模型能否落地的关键假设。

带来了什么新问题

验证越认真，成本越高。你需要设备暴露足够状态，需要可靠抓包点，需要保存配置和日志，需要构造背景压力，还需要长期观察异常。对小实验来说，这些可能显得繁琐；对工业现场来说，这些正是可信结论和演示效果之间的区别。

另一个问题是证据粒度。过粗的证据无法定位问题，过细的证据又难以维护。TSNBIT 后续的验证章节会继续讨论如何设计测试计划、如何组织报告、如何判断一份论文或产品白皮书里的评估是否足够可信。

检查点

• 如果测试报告只写“设备已同步”，但没有 offset 范围和 grandmaster 信息，你还需要补什么？
• 为什么 grandmaster 切换、holdover 和链路重连要单独列为验证场景？