为什么 gPTP 需要频差校正

解决什么问题

前面几节已经讲到，gPTP 通过 Sync / Follow_Up 传播 grandmaster 时间，通过 Pdelay 估计相邻链路延迟，并把 bridge 内部的 residence time 写进 correction field。这里还缺一个容易被忽略的问题：这些时间量很多都是由本地晶振驱动的计数器测出来的。

如果 grandmaster 的晶振和某个 bridge 的晶振频率不同，同样增加 1000000 个 tick，在两台设备眼里对应的真实时间并不完全相同。bridge 如果只用标称频率把本地 tick 换算成时间，就会把一个带有本地频率偏差的结果写进 correction field。下游节点再用这个 correction field 校正自己的时间，误差就会沿同步树继续传下去。

驻留时间为什么会出错

设一个 bridge 收到 Sync 时，本地计数器为 c1；转发 Sync 时，本地计数器为 c2。bridge 能直接看到的是 c2 - c1，也就是 Sync 在设备内部停留期间本地计数器增加了多少。

如果这个 bridge 按标称周期 DeltaT 换算，它会得到：

ResidentDelay(local) = (c2 - c1) * DeltaT

但 grandmaster 期望 correction field 里的 residence time 使用 grandmaster 的频率尺度来解释。若 GM 晶振频率为 fGM，bridge 本地晶振频率为 fB，那么同一段本地计数器跨度在 GM 尺度上的换算近似要乘上：

RateRatio(B) = fGM / fB

所以更接近 GM 期望的驻留时间是：

ResidentDelay(GM scale) = RateRatio(B) * ResidentDelay(local)

如果不乘这个比值，驻留时间越长，误差越大。这个结论很关键：频差本身可能只有几十 ppm，但 ppm 误差会乘上 residence time。硬件快速转发时 residence time 很短，影响可能不明显；如果 Sync 处理经过 CPU、驱动或用户态程序，驻留时间达到毫秒级，误差就可能进入百纳秒甚至更高量级。

一个量级例子

假设 grandmaster 的实际频率比标称值高 8ppm，某个 bridge 的实际频率比标称值低 48ppm。二者之间的频率差约为：

8ppm - (-48ppm) = 56ppm

如果 Sync 在这个 bridge 内部停留 8ms，那么仅由频差带来的驻留时间换算误差量级约为：

8ms * 56ppm = 8ms * 56 / 1,000,000
             = 448ns

448ns 看起来不大，但对亚微秒同步目标、很窄的 Qbv 窗口、或多跳同步树来说，它不是可以随手忽略的数字。更重要的是，这个误差不是随机噪声，而是由频率尺度不一致造成的系统性偏差。

路径延迟也受影响，但量级通常小得多

Pdelay 测相邻链路延迟时，也会用到两端设备的本地时间戳。理论上，频率差同样会让时间跨度换算出现误差。但链路路径延迟通常是 PHY、MAC 和线缆传播延迟的组合，千兆链路上常见量级是微秒级，而不是毫秒级。

如果一条链路路径延迟约为 5us，频差约为 56ppm，那么量级估算是：

5us * 56ppm = 0.28ns

这个量级通常远小于前面 8ms residence time 对应的 448ns。因此学习时可以先记住一个工程判断：频差对路径延迟测量不是没有影响，但更容易让人真正担心的是较长的 bridge residence time，尤其是软件参与同步报文处理的系统。

带来了什么新问题

既然问题来自 GM 和本地节点的频率比，gPTP 就需要让每个节点知道：我的本地计数器和 GM 的时间尺度之间相差多少。这个比值就是 RateRatio。

RateRatio 不能靠某个中心节点一次性告诉全网，因为每一跳都只直接看到自己的上游邻居。802.1AS 的思路是分布式的：下游节点测量自己和上游邻居的频比，同时从 Sync 中获得上游节点已经知道的 GM 频比，再把两者相乘，得到自己相对 GM 的频比。

下一节就讲这个分布式计算方法：NeighborRateRatio 怎么测，RateRatio 怎么沿同步树逐跳累乘，以及它如何进入 correction field 的 residence time 修正。

检查点

• 为什么 residence time 越长，频差校正越重要？
• 如果某个系统声称“软件处理 gPTP 也能满足亚微秒同步”，你会追问哪些驻留时间和 RateRatio 证据？