为什么共同时间先于调度
802.1Qbv 的 gate 可以配置成在某个时刻打开，但“某个时刻”必须被整条路径上的设备理解成同一个坐标。如果第一跳认为 1000 微秒到了，第二跳认为还差 20 微秒，同一份调度表就会在路径上错位。这个错位不一定立刻表现为丢包，它更常见的后果是窗口余量被吃掉、抓包时间戳互相矛盾、测试报告无法解释现场偶发迟到。
802.1AS，也就是 gPTP，在 TSN 里承担时间坐标系的角色。它不是为了让设备显示同一个墙上时间，而是为了让网络设备对发送窗口、接收窗口、测量时间戳和故障事件有共同解释。后面学习 Qbv、FRER、测试验证甚至论文里的 deadline 模型时，很多结论都默认“时间误差有边界”。
本章小节怎么读
先读“为什么需要共同时间”，把调度、测量和日志复盘放进同一个坐标系。然后读“时钟模型”，理解 offset、drift、phase、frequency 这些词描述的不是同一件事。接下来再看 grandmaster、同步报文和路径延迟测量，知道时间是如何沿网络传播的。
中间新增的频差校正两节，会把 802.1AS 里容易跳过的 RateRatio 单独讲清楚：为什么本地计数器测出的 residence time 不能直接写进 correction field，以及 NeighborRateRatio 如何沿同步树逐跳累乘。
最后读误差来源、误差预算和验证。这里会把共同时间和 Qbv 窗口直接接起来：窗口不是只容纳一个报文的发送时间，还要容纳同步不确定性、设备 gate 执行误差、路径延迟估计误差、频差校正残余误差和 guard band。
本章的核心结论
共同时间不是 TSN 的全部，但没有共同时间，很多 TSN 能力会失去可证明性。凡是谈 time-triggered、schedule、gate window、deadline、measurement accuracy 的高级主题，都隐含了一个时间同步质量假设。
这一章学完后，你不需要成为 802.1AS 协议实现者，但应该能看懂一个时间同步假设是否足够支撑后续调度结论。如果某个调度方案只写“使用 gPTP 同步”，却没有说明同步精度、路径延迟假设、设备执行误差和验证方式，那么它还没有给出完整工程证据。
检查点
- 如果两个交换机的本地时间相差 15 微秒，而关键窗口只有 30 微秒，这个窗口为什么会变脆弱？
- 如果一份测试报告只给出端到端平均延迟，没有说明各设备时间戳如何对齐，你会质疑什么？