同步报文怎么走：Sync、Follow_Up 与 Pdelay 的时间线

解决什么问题

前面已经知道共同时间需要两个信息：参考时间和链路延迟。本节把它们放到报文时间线上。你不需要在这里记住所有字段，但要理解为什么 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 等细节，但学习阶段先抓住“相邻链路、硬件时间戳、用于同步校正”这三个点。

时间线怎么读

可以用一个单跳例子建立直觉。上游设备在参考时间 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 估计比真实链路延迟小，接收端用它校正本地时钟时会出现什么风险？