解决什么问题
前面已经知道共同时间需要两个信息：参考时间和链路延迟。本节把它们放到报文时间线上。你不需要在这里记住所有字段，但要理解为什么 gPTP 不是一条“现在是几点”的广播消息。
一个同步报文从发送端进入网卡，到接收端离开网卡，中间会经历 PHY、MAC、交换芯片、驱动、操作系统等层次。对微秒级调度来说，软件层看到的时间通常太晚、太抖。gPTP 要尽量在靠近硬件的位置打时间戳，减少软件调度带来的不确定性。
Sync 与 Follow_Up
在两步时钟模式下，发送端先发 Sync。Sync 经过硬件发送点时，设备记录一个精确发送时间戳。由于这个精确时间戳往往只有帧真正发出时才知道，所以随后会用 Follow_Up 把这个精确发送时间告诉接收端。
接收端收到 Sync 时，也在硬件接收点记录接收时间戳。这样一来，它至少有两类时间：发送端说“我在某个参考时刻发出”，接收端说“我在本地某个时刻收到”。两者差值里包含链路延迟和本地时钟偏差。
Pdelay 在测什么
Pdelay 用来估计相邻两个 gPTP 节点之间的链路延迟。它不是测应用报文从 talker 到 listener 的端到端延迟，而是每一跳逐段估计相邻端口之间的传播/链路延迟。
简化理解时，可以把它看成一次问答：设备 A 发出 Pdelay 请求，设备 B 记录收到和回复的时间，设备 A 再记录回复到达时间。通过这些时间戳，A 可以估算 A-B 这条相邻链路的 delay。实际协议还会处理 correction、响应 follow-up 等细节，但学习阶段先抓住“相邻链路、硬件时间戳、用于同步校正”这三个点。
| 报文 | 主要作用 | 你要记住的直觉 |
|---|---|---|
| Sync | 传播一个同步事件 | 这是时间标记，不是完整答案 |
| Follow_Up | 携带精确发送时间和修正信息 | 让接收端知道 Sync 真正何时出端口 |
| Pdelay_Req/Resp | 测相邻链路延迟 | 帮助扣掉链路传播时间 |
时间线怎么读
可以用一个单跳例子建立直觉。上游设备在参考时间 T1 发出 Sync，下游设备在本地时间 T2 收到。随后 Follow_Up 告诉下游 T1 的精确值。与此同时，Pdelay 过程估计这条链路的 delay 约为 D。
下游设备要估计自己的 offset，本质上要回答：如果上游在 T1 发出，链路大约花了 D，那么我收到时对应的参考时间应接近 T1 + D。我的本地接收时间是 T2，所以本地时钟相对参考时间的偏差可以从 T2 与 T1 + D 的差里估算出来。
上游参考时间: T1 -------- Sync -------->
下游本地时间: T2
链路延迟估计: D
接收时参考时间约为: T1 + D
本地 offset 线索: T2 - (T1 + D)这个公式只是帮助理解方向，真实系统会叠加 correction field、bridge residence time、频率校正和滤波。但它足够说明一件事：路径延迟估计错误，会直接污染 offset 估计。
带来了什么新问题
同步报文时间线看似清楚，实际系统里有很多误差来源。硬件时间戳点是否一致，发送和接收路径是否对称，bridge 内部 residence time 是否稳定，Pdelay 响应是否被排队影响，都会进入最终时间误差。
这也是为什么“设备支持 gPTP”不是完整答案。工程上要进一步关心支持到什么精度、timestamp 在哪个层次、同步状态如何暴露、异常时如何告警。
检查点
- 两步时钟里，为什么 Follow_Up 对精确时间同步很重要？
- 如果 Pdelay 估计比真实链路延迟小，接收端用它校正本地时钟时会出现什么风险？