2.8 逐链路精准测量：P2P延迟测量机制

如果每一段路都有“测速仪“

想象你在高速公路上开车，想知道从北京到上海需要多长时间。

方法一：记录起点和终点时间

你从北京出发时看表：8:00 你到上海时看表：16:00 总时间：8小时

但这个时间包含了：

真正的行驶时间
服务区休息时间
堵车等待时间
吃饭时间

你不知道哪一段路花了多久。

方法二：每段路都有测速仪

高速公路在每个路段都安装了测速仪，记录你进入和离开每段路的时间：

北京-天津段：1小时
天津-济南段：2小时
济南-南京段：2.5小时
南京-上海段：2.5小时

你可以精确知道每一段的时间，也更容易发现问题（比如济南-南京段为什么这么慢？）。

PTP的两种延迟测量机制，就像这两种方法：

E2E机制：测量整个路径的总延迟
P2P机制：逐链路测量延迟

P2P机制的基本原理

核心思想

P2P（Peer-to-Peer，对等）机制的核心思想：让每两个相邻端口之间相互测量链路延迟。

不像E2E那样由从时钟测量到主时钟的整个路径，P2P让每个链路两端的设备各自测量自己之间的延迟。

消息交换过程

P2P机制涉及三类报文：

Pdelay_Req：请求者发送，请求测量链路延迟
Pdelay_Resp：响应者回复，携带接收时间戳
Pdelay_Resp_Follow_Up（可选）：响应者发送，携带发送时间戳

消息交换时序：

请求者（A）                               响应者（B）
    |                                         |
    |------ Pdelay_Req (t1) --------------->| (t2)
    |                                         |
    |<----- Pdelay_Resp (t4) ----------------| (t3)
    |                                         |
    |<----- Pdelay_Resp_Follow_Up (可选) ----|
    |                                         |

四个时间戳：

t1：请求者发送Pdelay_Req的时间
t2：响应者接收Pdelay_Req的时间
t3：响应者发送Pdelay_Resp的时间
t4：请求者接收Pdelay_Resp的时间

与E2E的关键区别

特性	E2E机制	P2P机制
谁发起测量	从时钟	每个端口（无论主从）
测量对象	主时钟到从时钟的整个路径	两个相邻端口之间的链路
报文类型	Sync + Delay_Req + Delay_Resp	Pdelay_Req + Pdelay_Resp + Pdelay_Resp_Follow_Up
透明时钟处理	E2E TC转发Delay_Req/Resp	P2P TC丢弃Delay_Req/Resp，响应Pdelay_Req
适用场景	通用	需要逐链路测量，或P2P TC网络

P2P机制的数学推导

基本公式

与E2E类似，P2P也使用四个时间戳计算延迟：

meanLinkDelay = [(t2 - t1) + (t4 - t3)] / 2

但有一个关键区别：t1、t2、t3、t4来自两个相邻的端口，而不是主时钟和从时钟。

这意味着：

t1和t4在请求者记录
t2和t3在响应者记录

one-step模式

在one-step模式下，Pdelay_Resp报文直接携带时间信息。

响应者的处理：

响应者收到Pdelay_Req时记录t2，发送Pdelay_Resp时记录t3。

Pdelay_Resp.correctionField携带：(t3 - t2)，即响应者的周转时间。

请求者的计算：

meanLinkDelay = [(t4 - t1) - Pdelay_Resp.correctionField] / 2
              = [(t4 - t1) - (t3 - t2)] / 2
              = [(t2 - t1) + (t4 - t3)] / 2

two-step模式

在two-step模式下，Pdelay_Resp后跟Pdelay_Resp_Follow_Up。

响应者的处理：

响应者收到Pdelay_Req时记录t2，发送Pdelay_Resp时记录t3。

Pdelay_Resp携带t2（requestReceiptTimestamp）。

Pdelay_Resp_Follow_Up携带t3（responseOriginTimestamp）。

请求者的计算：

meanLinkDelay = [(t4 - t1) - (responseOriginTimestamp - requestReceiptTimestamp)] / 2
              = [(t4 - t1) - (t3 - t2)] / 2

为什么有两种模式？

one-step模式：

优点：只需要两个报文，效率高
缺点：需要在发送Pdelay_Resp时精确测量t3，硬件要求高

two-step模式：

优点：可以在发送Pdelay_Resp_Follow_Up时携带精确的t3，实现简单
缺点：需要三个报文，开销大

大多数商业设备使用two-step模式，因为实现更简单。

一个完整的P2P测量示例

场景

端口A ---- 链路 ---- 端口B

参数：

真实链路延迟：100ns（对称）
端口A的时间：正常
端口B的时间：正常（假设已经同步）

消息交换

步骤1：端口A发送Pdelay_Req

发送时间：t1 = 1000.000000000秒

步骤2：端口B接收Pdelay_Req

接收时间：t2 = 1000.000000100秒（100ns后）

步骤3：端口B发送Pdelay_Resp

发送时间：t3 = 1000.000001000秒（假设处理延迟900ns）

步骤4：端口A接收Pdelay_Resp

接收时间：t4 = 1000.000001100秒（t3 + 100ns）

计算

四个时间戳：

t1 = 1000.000000000秒
t2 = 1000.000000100秒
t3 = 1000.000001000秒
t4 = 1000.000001100秒

计算meanLinkDelay：

meanLinkDelay = [(t2 - t1) + (t4 - t3)] / 2
              = [(100ns) + (100ns)] / 2
              = 100ns

正确！

注意：响应者的周转时间（t3 - t2 = 900ns）不影响测量结果，因为被减掉了。

P2P机制与透明时钟

P2P透明时钟的特殊处理

P2P透明时钟（P2P TC）不仅要测量驻留时间，还要：

测量链路延迟：对每个端口，使用P2P机制测量与对端的链路延迟
累加到correctionField：转发Sync时，把驻留时间 + 入口链路延迟累加

P2P TC的工作流程

场景：

主时钟 ---- TC_B ---- 从时钟

TC_B的端口1（连接主时钟）：

定期发送Pdelay_Req给主时钟
收到Pdelay_Resp，计算meanLinkDelay_1
监听主时钟的Sync报文

TC_B的端口2（连接从时钟）：

定期发送Pdelay_Req给从时钟
收到Pdelay_Resp，计算meanLinkDelay_2
向从时钟转发Sync报文

转发Sync的处理：

当Sync报文从端口1进入，从端口2离开：

Sync.correctionField（出口） = Sync.correctionField（入口） 
                              + residenceTime 
                              + meanLinkDelay_1
                              + ingressDelayAsymmetry

关键：meanLinkDelay_1是入口链路的延迟（主时钟→TC_B）。

P2P vs E2E：深度对比

测量粒度

E2E：

测量整个路径的延迟
包含所有链路延迟 + 所有透明时钟驻留时间
无法区分哪一段贡献了多少延迟

P2P：

测量每个链路的延迟
可以精确知道每段链路的延迟
便于诊断和优化

不对称处理

E2E：

整个路径的不对称会影响offsetFromMaster
难以分别处理各段不对称
依赖配置的delayAsymmetry值

P2P：

每段链路的不对称独立处理
可以分别配置各段的不对称
更精细的控制

网络规模影响

E2E：

从时钟数量增加，Delay_Req报文数量线性增加
主时钟负载重
可能成为瓶颈

P2P：

每个端口独立测量，负载分散
不存在中心瓶颈
更适合大规模网络

收敛速度

E2E：

新设备加入时，需要完整的消息交换
收敛速度取决于Sync和Delay_Req的间隔
典型收敛时间：几秒到几十秒

P2P：

新设备加入时，立即开始P2P测量
测量完成后再转发Sync
收敛速度更快

网络拓扑要求

E2E：

对拓扑无特殊要求
可以有普通交换机（非PTP设备）在中间
兼容性好

P2P：

要求所有设备支持P2P机制
中间不能有普通交换机
要求更严格

报文数量

E2E：

每个从时钟：1个Delay_Req + 1个Delay_Resp
报文数量 = 2 × 从时钟数量

P2P：

每个链路：1个Pdelay_Req + 1个Pdelay_Resp（+ 1个Pdelay_Resp_Follow_Up可选）
报文数量 = 2（或3）× 链路数量

对比：

假设：

网络有100个设备，形成树状拓扑
从时钟数量：99个
链路数量：99条

E2E报文数量：2 × 99 = 198个

P2P报文数量：2 × 99 = 198个（one-step）或 3 × 99 = 297个（two-step）

看起来差不多？但实际上：

E2E的报文由从时钟发送，所有Delay_Req都发往主时钟，主时钟负载重。

P2P的报文由每个端口发送，负载分散到整个网络。

P2P机制的典型应用场景

场景一：TSN网络（时间敏感网络）

TSN（Time-Sensitive Networking）是IEEE 802.1定义的一组标准，用于在以太网上提供实时性保障。

TSN使用IEEE 802.1AS Profile，基于PTP，但要求：

所有设备支持P2P机制
使用P2P透明时钟
实现亚微秒级同步

为什么TSN选择P2P？

TSN网络通常用于工业自动化、汽车电子等场景，要求：

快速收敛（设备加入后快速同步）
确定性延迟（每段链路延迟已知）
高可靠性（故障快速切换）

P2P机制可以满足这些要求。

场景二：电信网络

ITU-T定义了G.8275.1和G.8275.2 Profile，用于电信网络的时间同步。

这些Profile也倾向于使用P2P机制，原因：

电信网络规模大，需要负载分散
需要快速收敛，支持设备热插拔
需要精细的不对称控制

场景三：White Rabbit

White Rabbit是一个开源的超高精度同步方案，基于PTP + SyncE（同步以太网）。

White Rabbit使用P2P机制，并扩展了：

精确的链路延迟测量（使用DDMTD相位检测器）
频率同步（通过SyncE）
不对称校准（硬件测量光纤不对称）

可以实现亚纳秒级同步。

P2P机制的实现挑战

挑战一：所有设备必须支持P2P

P2P机制要求网络中所有设备都支持P2P。

如果中间有普通交换机（不支持P2P），会发生什么？

问题：

普通交换机不会响应Pdelay_Req，P2P测量失败。

如果多个设备连接到同一个普通交换机，一个Pdelay_Req可能被多个设备接收，违反P2P的“一对一“假设。

解决方案：

网络规划时，确保所有设备支持P2P
或使用边界时钟隔离不支持P2P的区域

挑战二：频繁的P2P测量

P2P机制要求每个端口定期发送Pdelay_Req，可能增加CPU和网络负载。

建议：

根据网络稳定性调整Pdelay_Req间隔
稳定网络可以用较大间隔（如1秒）
不稳定网络可以用较小间隔（如100毫秒）

挑战三：多端口设备的资源管理

边界时钟和P2P透明时钟有多个端口，每个端口都需要：

独立的P2P状态机
独立的meanLinkDelay存储
独立的Pdelay报文发送/接收

资源消耗：

每端口：~几KB内存
每端口：独立的定时器
报文处理：每秒几到几十个Pdelay报文

对于64端口交换机，这些资源累加起来也是可观的。

一个完整的P2P网络示例

网络拓扑

主时钟A ---- P2P_TC_B ---- P2P_TC_C ---- 从时钟D

初始化阶段

P2P_TC_B的端口1与主时钟A建立P2P测量：

P2P_TC_B端口1发送Pdelay_Req
主时钟A回复Pdelay_Resp
P2P_TC_B端口1计算meanLinkDelay_AB = 100ns

P2P_TC_B的端口2与P2P_TC_C端口1建立P2P测量：

P2P_TC_B端口2发送Pdelay_Req
P2P_TC_C端口1回复Pdelay_Resp
P2P_TC_B端口2计算meanLinkDelay_BC = 150ns

P2P_TC_C的端口2与从时钟D建立P2P测量：

P2P_TC_C端口2发送Pdelay_Req
从时钟D回复Pdelay_Resp
P2P_TC_C端口2计算meanLinkDelay_CD = 120ns

同步阶段

主时钟A发送Sync：

originTimestamp = 1000.000000000秒
correctionField = 0

P2P_TC_B处理Sync：

收到Sync（端口1）：

记录ingress时间戳
originTimestamp = 1000.000000000秒
correctionField = 0

转发Sync（端口2）：

计算驻留时间：residenceTime_B = 5μs
meanLinkDelay_AB = 100ns
ingressAsymmetry = 0

更新correctionField：

correctionField = 0 + 5μs + 100ns + 0 = 5.1μs

P2P_TC_C处理Sync：

收到Sync（端口1）：

correctionField = 5.1μs

转发Sync（端口2）：

计算驻留时间：residenceTime_C = 3μs
meanLinkDelay_BC = 150ns
ingressAsymmetry = 0

更新correctionField：

correctionField = 5.1μs + 3μs + 150ns + 0 = 8.25μs

从时钟D接收Sync：

originTimestamp = 1000.000000000秒
correctionField = 8.25μs
meanLinkDelay_CD = 120ns（已通过P2P测量）

计算主时钟真实发送时间：

主时钟发送时间（校正后） = originTimestamp + correctionField
                        = 1000.000000000 + 0.00000825
                        = 1000.000008250秒

路径延迟 = meanLinkDelay_CD = 120ns

主时钟真实发送时间（在从时钟接收时刻） = 1000.000008250 + 0.000000120
                                       = 1000.000008370秒

从时钟可以根据这个时间调整自己的时钟。

关键点：从时钟不需要发送Delay_Req，因为路径延迟已经被P2P TC累加到correctionField中了。

小结：P2P机制的核心要点

核心思想：

逐链路测量延迟
每个端口独立测量与对端的链路延迟
P2P TC累加链路延迟到correctionField

消息交换：

Pdelay_Req：请求者发送
Pdelay_Resp：响应者回复
Pdelay_Resp_Follow_Up：可选，携带精确时间戳

核心公式：

meanLinkDelay = [(t2 - t1) + (t4 - t3)] / 2

P2P TC的处理：

Sync.correctionField += residenceTime + meanLinkDelay + ingressAsymmetry

与E2E的对比：

特性	E2E	P2P
测量对象	整个路径	每个链路
报文数量	2×从时钟数	2-3×链路数
负载分布	主时钟集中	全网分散
网络要求	无特殊要求	所有设备支持P2P
收敛速度	较慢	较快
不对称处理	粗粒度	细粒度

适用场景：

TSN网络
电信网络
White Rabbit
大规模、高精度要求网络

下集预告

现在，我们知道了如何测量路径延迟（E2E）和链路延迟（P2P）。

但我们还有一个关键问题没有深入讨论：从时钟如何根据测量结果调整自己的时钟？

知道了offsetFromMaster = +50ns，从时钟应该怎么做？

直接跳变？还是渐进调整？
如何避免时钟倒退？
如何同时调整相位和频率？

下一节，我们将深入讲解时钟调整的数学和工程实现——从时间戳到时钟调整。

【悬念留给2.9】

你可能觉得：知道offset了，直接加上或减去不就行了吗？

但事情没那么简单。如果从时钟直接跳变，可能导致：

时间戳不连续

日志时间倒退

应用程序崩溃

更重要的是：offset不是恒定的。每次测量，offset都不同。如何从一系列offset值中，提取出“真正的“时间偏差和频率偏差？

这就涉及到时钟伺服算法——一个控制理论在PTP中的应用。

下一节，我们详细解读。

Keyboard shortcuts

汽车电子七部曲