2.7 四个时间戳的魔法：E2E延迟测量机制
一个看似简单的问题
假设你想测量一个网球从你手里飞到墙壁，再弹回来的时间。
最简单的方法：
- 你看手表，记录发球时间：10:00:00.000
- 球弹回来，你看手表，记录接球时间：10:00:02.500
- 往返时间 = 2.500秒
但PTP面临的问题比这复杂得多。
问题一：主时钟和从时钟的时间不一致。你用你的手表，我用我的手表，两个手表可能差几秒甚至几分钟。
问题二：往返路径不对称。球去和回来的速度可能不同。
问题三：我们无法直接测量“单程时间“，只能测量“往返时间“。
PTP如何解决这些问题？
答案就在四个时间戳。
E2E机制的基本原理
消息交换过程
E2E（End-to-End，端到端）延迟测量机制涉及三类报文：
- Sync：主时钟发送，携带发送时间戳
- Delay_Req：从时钟发送，请求测量
- Delay_Resp：主时钟回复，携带接收时间戳
消息交换时序：
主时钟 从时钟
| |
|------ Sync (t1) ----------------------->| (t2)
| |
|<----- Delay_Req ------------------------| (t3)
| |
|------ Delay_Resp (t4) ----------------->|
| |
四个时间戳：
- t1：主时钟发送Sync的时间（主时钟的时间）
- t2：从时钟接收Sync的时间（从时钟的时间）
- t3：从时钟发送Delay_Req的时间（从时钟的时间）
- t4：主时钟接收Delay_Req的时间（主时钟的时间）
关键洞察
注意这四个时间戳的特点：
- t1和t4：主时钟记录的，使用主时钟的时间基准
- t2和t3：从时钟记录的，使用从时钟的时间基准
问题是：主时钟和从时钟的时间基准不一致。
假设从时钟比主时钟快了100纳秒（offset = +100ns）。
那么：
- 从时钟的“1000秒“，实际上是主时钟的“999.9999999秒“
- 从时钟记录的t2和t3，都比主时钟的“真实时间“快了100ns
如何消除这个时间偏差的影响？
这就是PTP算法的精妙之处。
数学推导：从四个时间戳到两个关键值
定义
设：
- offset：从时钟相对于主时钟的时间偏差
- offset > 0：从时钟比主时钟快
- offset < 0：从时钟比主时钟慢
- delay：单程传播延迟（假设对称，即主→从 = 从→主）
时间关系
Sync报文传播过程：
主时钟在真实时间T1发送Sync，主时钟读数 = t1
Sync经过delay时间到达从时钟
从时钟在真实时间T1 + delay接收Sync，从时钟读数 = t2
由于从时钟比主时钟快offset：
从时钟读数 = 主时钟读数 + offset
因此：
t2 = t1 + delay + offset ... (公式1)
Delay_Req报文传播过程：
从时钟在真实时间T3发送Delay_Req，从时钟读数 = t3
Delay_Req经过delay时间到达主时钟
主时钟在真实时间T3 + delay接收Delay_Req，主时钟读数 = t4
同样考虑offset：
t3 = t4 - delay + offset ... (公式2)
求解
我们有两个方程，两个未知数（delay和offset）。
从公式1：
t2 - t1 = delay + offset
offset = t2 - t1 - delay ... (公式1a)
从公式2：
t3 - t4 = -delay + offset
offset = t3 - t4 + delay ... (公式2a)
联立方程：
公式1a = 公式2a：
t2 - t1 - delay = t3 - t4 + delay
解：
t2 - t1 - t3 + t4 = 2 × delay
delay = [(t2 - t1) + (t4 - t3)] / 2 ... (公式3)
这就是meanPathDelay（平均路径延迟）的计算公式。
代入求offset：
将delay代入公式1a：
offset = t2 - t1 - [(t2 - t1) + (t4 - t3)] / 2
= [(t2 - t1) - (t4 - t3)] / 2 ... (公式4)
这就是offsetFromMaster（主从时间偏差）的计算公式。
一个完整的数值例子
让我们用一个具体的数值例子，演示整个计算过程。
场景设置
假设：
- 主时钟和从时钟之间的真实传播延迟：100纳秒（对称）
- 从时钟比主时钟快：50纳秒（offset = +50ns）
主时钟在1000.000000000秒发送Sync：
- t1 = 1000.000000000秒（主时钟读数）
- Sync经过100ns到达从时钟
- 从时钟在真实时间1000.000000100秒接收Sync
- 从时钟读数 = 1000.000000100 + 50ns = 1000.000000150秒
- t2 = 1000.000000150秒
从时钟在1000.001000000秒发送Delay_Req：
- t3 = 1000.001000000秒（从时钟读数）
- 真实时间 = 1000.001000000 - 50ns = 1000.000999950秒
- Delay_Req经过100ns到达主时钟
- 主时钟在真实时间1000.001000050秒接收Delay_Req
- 主时钟读数 = 1000.001000050秒
- t4 = 1000.001000050秒
计算
四个时间戳：
- t1 = 1000.000000000秒
- t2 = 1000.000000150秒
- t3 = 1000.001000000秒
- t4 = 1000.001000050秒
计算meanPathDelay：
meanPathDelay = [(t2 - t1) + (t4 - t3)] / 2
= [(150ns) + (50ns)] / 2
= 200ns / 2
= 100ns
正确！ 真实延迟确实是100ns。
计算offset：
offset = [(t2 - t1) - (t4 - t3)] / 2
= [150ns - 50ns] / 2
= 100ns / 2
= 50ns
正确！ 从时钟确实比主时钟快50ns。
验证
让我们验证一下这个结果的正确性。
假设从时钟根据offset调整时间：
从时钟知道offset = +50ns，于是将自己的时间减去50ns。
调整后的从时钟时间：
- 原始读数：1000.000000150秒
- 减去offset：1000.000000150 - 50ns = 1000.000000100秒
与主时钟对比：
- 主时钟发送Sync的真实时间：1000.000000000秒
- 主时钟发送后100ns，从时钟接收
- 从时钟调整后的时间：1000.000000100秒
- 主时钟当时的真实时间：1000.000000100秒
完全一致！ 同步成功。
实际实现：考虑correctionField
上面的推导假设：
- 报文传播完全对称
- 没有透明时钟
- 没有其他延迟
实际上，PTP报文可能经过透明时钟，correctionField会被累加。
完整的计算公式
meanPathDelay：
meanPathDelay = [(t2 - t1) + (t4 - t3)
- correctedSyncCorrectionField
- Delay_Resp.correctionField] / 2
其中：
- correctedSyncCorrectionField = Sync.correctionField + ingressDelayAsymmetry
offsetFromMaster：
one-step模式：
offsetFromMaster = t2 - originTimestamp - meanPathDelay - correctedSyncCorrectionField
two-step模式：
offsetFromMaster = t2 - preciseOriginTimestamp - meanPathDelay
- correctedSyncCorrectionField - Follow_Up.correctionField
correctionField的含义
Sync.correctionField包含：
- 主时钟的小数纳秒部分（originTimestamp无法表示的部分）
- 所有透明时钟的驻留时间
- 所有透明时钟的入口不对称校正值
Follow_Up.correctionField包含：
- two-step模式下的精确时间戳补充
- 透明时钟累加的校正值
Delay_Resp.correctionField包含：
- Delay_Req路径上透明时钟的驻留时间
- Delay_Req路径上透明时钟的出口不对称校正值
不对称的影响
对称假设
E2E机制的核心假设：主→从延迟 = 从→主延迟。
如果这个假设成立，meanPathDelay的计算是准确的。
如果不对称？
假设：
- 主→从延迟：100ns
- 从→主延迟：150ns
- 真实平均延迟：125ns
- 不对称量：25ns
计算meanPathDelay：
meanPathDelay = [(t2 - t1) + (t4 - t3)] / 2
= [主→从延迟 + 从→主延迟] / 2
= [100ns + 150ns] / 2
= 125ns
meanPathDelay是正确的！
但offset的计算会出错：
offset = [(t2 - t1) - (t4 - t3)] / 2
= [主→从延迟 - 从→主延迟] / 2
= [100ns - 150ns] / 2
= -25ns
问题：这个-25ns是不对称引入的误差，会叠加到真实的offset上。
不对称误差的量化
设：
- t_ms = 主→从延迟
- t_sm = 从→主延迟
- 真实不对称 = delayAsymmetry = (t_ms - t_sm) / 2
则：
计算的offset = 真实offset + delayAsymmetry
示例：
假设：
- 真实offset = +50ns
- t_ms = 100ns, t_sm = 150ns
- delayAsymmetry = (100 - 150) / 2 = -25ns
计算：
计算的offset = 50ns + (-25ns) = 25ns
误差 = 25ns，从时钟以为自己只快了25ns，实际上快了50ns。
如何应对不对称？
方法一：测量并配置不对称值
如果已知链路的不对称（例如光纤长度差），可以通过管理接口配置portDS.delayAsymmetry。
PTP会在计算时补偿这个值。
方法二：使用P2P机制
P2P机制逐链路测量延迟，可以更好地控制不对称。但P2P也有自己的不对称问题（见下一节）。
方法三：外部校准
使用外部测量设备（如示波器、时间间隔计数器）测量实际不对称，然后配置到PTP设备中。
Delay_Req的发送时机
两种模式
模式一：周期性发送
从时钟按照logMinDelayReqInterval规定的间隔，周期性发送Delay_Req。
优点：
- 简单
- 可预测
缺点：
- 浪费带宽（即使不需要测量延迟）
- 延迟测量的更新频率固定
模式二：事件触发
从时钟在收到Sync报文后，立即发送Delay_Req。
优点：
- 及时更新延迟测量
- 减少延迟（Sync和Delay_Req紧挨着）
缺点：
- 可能增加网络突发流量
PTP标准的要求
PTP标准规定：
- 连续两个Delay_Req的最小间隔应 ≥ 0.9 × 2^(logMinDelayReqInterval)
- 从时钟应尊重主时钟通告的logMinDelayReqInterval
示例：
如果主时钟通告logMinDelayReqInterval = 0（即间隔1秒），从时钟发送Delay_Req的间隔应 ≥ 0.9秒。
一个完整的E2E测量流程示例
场景
主时钟A ---- TC_B ---- 从时钟C
参数：
- 主时钟A发送Sync时间：t1 = 1000.000000000秒
- TC_B驻留时间：5μs
- TC_B入口不对称：0
- TC_B出口不对称：0
- A→C真实传播延迟：100ns + 5μs = 5.1μs
消息交换
步骤1：主时钟A发送Sync
- originTimestamp = 1000.000000000秒
- correctionField = 0
步骤2：Sync经过TC_B
- TC_B测量驻留时间：5μs
- 更新correctionField：0 + 5μs = 5μs
步骤3：从时钟C接收Sync
- 接收时间戳：t2 = 1000.000005100秒 （包含5μs驻留时间 + 100ns传播延迟）
- Sync.correctionField = 5μs
步骤4：从时钟C发送Delay_Req
- 发送时间戳：t3 = 1000.010000000秒
- Delay_Req.correctionField = 0
步骤5：Delay_Req经过TC_B
- TC_B测量驻留时间：5μs
- 更新correctionField：0 + 5μs = 5μs
步骤6：主时钟A接收Delay_Req
- 接收时间戳：t4 = 1000.010005050秒 （从时钟发送时间 + 传播延迟 + 驻留时间）
步骤7：主时钟A发送Delay_Resp
- receiveTimestamp = t4 = 1000.010005050秒
- Delay_Resp.correctionField = 5μs
步骤8：Delay_Resp经过TC_B
- TC_B测量驻留时间：5μs
- 更新correctionField：5μs + 5μs = 10μs
步骤9：从时钟C接收Delay_Resp
- Delay_Resp.receiveTimestamp = 1000.010005050秒
- Delay_Resp.correctionField = 10μs
计算
四个时间戳：
- t1 = 1000.000000000秒
- t2 = 1000.000005100秒
- t3 = 1000.010000000秒
- t4 = 1000.010005050秒
校正字段：
- Sync.correctionField = 5μs
- Delay_Resp.correctionField = 10μs
- ingressDelayAsymmetry = 0
- correctedSyncCorrectionField = 5μs + 0 = 5μs
计算meanPathDelay：
下面的例子展示如何正确计算。假设：
- 主时钟和从时钟之间的传播延迟：100ns
- 从时钟比主时钟快：50ns
t1 = 1000.000000000秒
t2 = 1000.000000150秒（包含100ns延迟 + 50ns offset）
t3 = 1000.010000000秒
t4 = 1000.010000050秒（包含100ns延迟，减去50ns offset）
计算meanPathDelay：
meanPathDelay = [(t2 - t1) + (t4 - t3)] / 2
= [(150ns) + (50ns)] / 2
= 100ns
计算offset：
offset = [(t2 - t1) - (t4 - t3)] / 2
= [(150ns) - (50ns)] / 2
= 50ns
E2E机制的优缺点
优点
1. 端到端测量
直接测量主时钟到从时钟的整个路径延迟，不需要中间设备支持P2P机制。
2. 简单
只需要三类报文（Sync、Delay_Req、Delay_Resp），实现相对简单。
3. 兼容透明时钟
透明时钟可以正确处理Sync和Delay_Req，累加驻留时间。
4. 适合层级网络
在有多级边界时钟的网络中，E2E机制可以正确工作。
缺点
1. 依赖对称性
假设往返延迟对称，如果不对称，会引入误差。
2. 测量延迟较大
需要四次消息交换（Sync + Delay_Req + Delay_Resp），测量延迟较大。
3. 报文数量多
每个从时钟都需要发送Delay_Req，在大规模网络中，报文数量可能很大。
4. 主时钟负载重
主时钟需要响应所有从时钟的Delay_Req，负载可能很重。
小结：E2E机制的核心要点
基本原理：
- 主时钟发送Sync，记录发送时间戳t1
- 从时钟接收Sync，记录接收时间戳t2
- 从时钟发送Delay_Req，记录发送时间戳t3
- 主时钟接收Delay_Req，记录接收时间戳t4
- 从时钟收到Delay_Resp，获取t4
核心公式：
meanPathDelay = [(t2 - t1) + (t4 - t3)] / 2
offsetFromMaster = [(t2 - t1) - (t4 - t3)] / 2
关键假设：
- 往返延迟对称
- 主时钟和从时钟的频率一致（或接近）
不对称影响：
- meanPathDelay不受影响
- offsetFromMaster会引入误差 = delayAsymmetry
实际计算：
- 需要考虑correctionField
- 需要考虑透明时钟的驻留时间
- 需要考虑不对称校正值
下集预告
现在，我们知道了E2E机制如何用四个时间戳测量路径延迟。
但E2E机制有一个关键假设：往返延迟对称。如果不对称，会引入误差。
更重要的是，E2E机制测量的是整个路径的延迟，无法感知中间每一段链路的延迟。
有没有一种机制，可以逐链路测量延迟，并且更好地处理不对称？
答案就是：P2P机制。
下一节，我们将深入讲解P2P延迟测量机制——如何用Pdelay_Req/Pdelay_Resp逐链路测量延迟。
【悬念留给2.8】
P2P机制的精妙之处在于：它让每个链路两端的设备相互测量链路延迟，而不是让从时钟测量整个路径。
这样做的好处是：每个链路的延迟测量是独立的，不受网络规模的影响。
但代价是：所有设备都必须支持P2P机制，不能有“不支持P2P的设备“在中间。
下一节，我们详细解读P2P机制的工作原理和适用场景。