解决什么问题
上一节讲了本地时钟会有 offset 和 drift。本节回答下一个问题：网络里到底由谁给出参考时间，参考时间如何传到其他设备，接收方又怎么知道报文在链路上花了多少时间。
如果只把 grandmaster 的时间戳发给下游设备，下游设备仍然不知道这个时间戳对应自己本地的哪个时刻。因为同步报文从发送端到接收端需要传播时间、PHY/MAC 处理时间，还可能经过 bridge 的驻留时间。gPTP 必须把“时间是什么”和“这条链路花了多久”一起处理。
背景与直觉
grandmaster 可以理解成时间域里的参考源。其他设备不是盲目相信自己的本地晶振，而是根据同步信息不断校正。一个 TSN 时间域通常会形成一棵时间传播树：grandmaster 在上游，bridge 和 end station 沿路径接收、修正、再传播时间信息。
这里有一个关键直觉：同步报文本身也是网络里的帧，它不是瞬间到达。如果发送端在 T1 时刻发出 Sync，接收端在自己的本地 T2 时刻收到，那么 T2 里混合了两类信息：发送端时间、链路延迟、本地时钟偏差。只有估计链路延迟，接收端才有可能把这些因素拆开。
怎么解决
gPTP 网络会选择或配置 grandmaster，并让时间信息沿网络传播。每个节点通过接收同步信息、测量相邻链路延迟、校正本地时钟，逐步靠近共同时间。交换机在这个过程中不是透明管道，它们也参与时间信息转发和校正。
学习阶段不需要立即掌握所有报文字段，但要抓住四个变量。
- grandmaster 质量：参考源本身是否稳定，发生切换时会不会造成时间突变。
- 本地 oscillator：设备两次同步之间会不会快速漂移。
- peer delay 估计：链路延迟测得准不准，链路是否对称。
- residence time：同步信息经过 bridge 时，设备内部处理和停留时间是否被正确计入。
如果这四类信息中任何一类没有边界，后面的调度窗口就只能靠经验放宽，而不是可解释地计算余量。
| 角色/量 | 解决的问题 | 如果估错会怎样 |
|---|---|---|
| grandmaster | 提供参考时间 | 整个时间域一起偏移或切换抖动 |
| Sync / Follow_Up | 传播参考时间点 | 接收端不知道上游时间对应何时 |
| peer delay | 估计相邻链路延迟 | 本地校正时扣多或扣少 |
| residence time | 估计 bridge 内部停留 | 多跳传播误差逐跳积累 |
带来了什么新问题
共同时间本身也有工程成本。grandmaster 失效怎么办，时钟质量如何比较，链路延迟变化如何处理，设备时间戳精度够不够，网络里是否存在不支持时间同步的中间节点，这些都会影响最终边界。
更关键的是，时间同步误差会向后传递。Qbv 的窗口看起来很宽，但如果时钟偏差、执行延迟和 guard band 吃掉了大部分余量，关键帧仍可能错过窗口。
检查点
- 为什么接收端不能只看 Sync 报文里的发送时间，就直接校正自己的时钟？
- 如果一条链路的 peer delay 被低估了 5us，下游设备的共同时间理解可能出现什么方向的偏差？