IEEE1588v2解析（4）--透明时钟/一步时钟/二步时钟

Simple-Easy 化繁为简

已于 2022-05-28 08:07:14 修改

阅读量7.8k

点赞数 11

文章标签： PTP 透明时钟 correction 误差矫正

于 2022-05-27 20:04:29 首次发布

本文链接：https://blog.csdn.net/weixin_43408952/article/details/125009747

版权

透明时钟是PTP协议里面最复杂和最难理解的部分；下面是全网最清晰的透明时钟介绍。

在介绍透明时钟之前，需要先介绍下PTP协议的报文类型：

PTP报文分两种大类，

一类是Event报文：

Sync，同步消息 , 由主设备发送给从设备 , 消息中可以包含 Sync 发送时间标签 , 也可以在后续的Follow UP 消息中包含 ;
Delay_Req，请求对端返回接收到 Delay Req消息时的时间标签 , 时间标签嵌入在响应消息Delay Resp
Pdelay_Req，用于发起链路延时测量请求 , 带发送时间标签。
Pdelay_Resp

这类型报文有个特别的要求，即发送和接收这些报文的端口需要记录发送时间点或者接收时间点。

另一类是general报文：

Announce
Follow_Up
Delay_Resp
Pdelay_Resp_Follow_Up
Management
Signaling

报文的公共header：

sourcePort Identity用来区分请求发起方的端口
correctionField用来存储时间信息，单位为纳秒，具体取值除以2的16次方以后是真正的值，也就是最低的16bit可以表示小于纳秒的值
flagField里面的twostep标志位，可以用来标识是否采用二步时钟

不同消息内容的定义：

一步时钟 one-step clock：使用单个Event报文（比如Sync）来提供时间信息的时钟；

二步时钟 two-step clock：使用一个Event报文（比如Sync）和紧接着的一个general报文（比如follow up）来提供时间信息的时钟。

比如普通时钟/边界时钟作为主时钟时候，可以是一步时钟，也可以是二步时钟，一般取决于硬件标记时间戳的性能，能力强的可以一步，这个在前面的文章中提到过。

透明时钟：一个设备，可以测量PTP event报文经过自己的所花费时间（residence time），并且将此时间添加到PTP报文里面。本身并不需要和grandmater进行时间同步，通常保持频率同步即可。需要转发所有非PTP报文。

透明时钟的分类：

端到端的时钟 E2E TC
- 转发所有PTP报文
- 对于Sync, Follow_Up和Delay_Req报文按照规范要求进行residence time的处理
- 不支持PeertoPeer的路径测量
点到点的时钟 P2P TC
- 执行PeertoPeer的路径测量
- 转发Announce, Sync, Follow_Up, Management, Signaling 报文；
- 扔掉Delay_Req 和 Delay_Resp报文
- Sync 和 Follow_Up报文需要按照规范要求进行residence time的处理。

上面两种时钟，可以是一步时钟，也可以是二步时钟；

在同一通信链路上，不允许同时存在E2E TC和P2P TC。

下面谈一下透明时钟的作用：

透明时钟通常是网络交换机类型的设备，当交换机上有大量数据流量时候，会出现报文排队，每个端口的排队情况都不会一样，PTP的路径计算假设了链路时延是对称的，也就是主时钟到从时钟的时延和从时钟到主时钟的时延相等，对于线路上，这种假设一般是成立的，但是线路上还存在交换机类设备，那么由于排队情况的存在，两个方向的时延并不一定是相同的，这样就会引入误差，通过在交换机的端口上启用透明时钟，可以把经过自身的排队时间放在PTP报文上，这样从时钟在处理PTP报文时候，可以消除两个方向上排队时间带来的差异，这样能大大提高时间同步的准确度。

下面是透明时钟如何消除差异的原理分析，

首先看E2E TC（二步时钟）的情况：

如果收到Sync报文的twoStepFlag 是FALSE，代表后续不会收到follow up报文。透明时钟转发Sync报文，并将twoStepFlag修改为True，并计算和记录Sync报文经过它时候花费的时间residence time（master到slave的方向的排队时间，记为C1）
然后透明时钟需要自己产生follow_up报文，因为自己是二步时钟，此时需要把Sync报文的originTimestamp（也就是t1）放在follow_up的preciseOriginTimestamp；follow_up的twoStepFlag也是Ture。
residence time需要放在follow_up的correctionField。
然后发送follow_up。
如果收到了Delay_req消息，那么需要计算Delay_req经过自己时候花费的时间residenceTime（slave到master的方向的排队时间，记为C2），然后转发Delay_req。
后续接收到Delay_resp的消息后，将residence time需要放在Delay_resp的correctionField，然后转发Delay_resp。

路径时延计算：

<meanPathDelay> =[(t2 - t3) +(t4 - t1)]/2= [(t2 - t3) + (receiveTimestamp of
Delay_Resp message(t4的纳秒以上部分) – preciseOriginTimestamp of Follow_Up message(t1的纳秒以上部分)) – correctionField of
Sync message（取值0）– correctionField of Follow_Up message（取值为：t1的小于纳秒的部分 + C1） – correctionField of Delay_Resp
message（取值为：C2 - t4的小于纳秒的部分）]/2 = [(t2 - t3) +(t4 - t1)]/2-(C1+C2)/2 = [(t2 - t1) +(t4 - t3)]/2- (C1+C2)/2

时钟偏差值计算：

<offsetFromMaster> = t2-t1-<meanPathDelay> = <syncEventIngressTimestamp>（即t2） - <preciseOriginTimestamp>（即t1大于纳秒部分） -
<meanPathDelay> - correctionField of Sync message（取值0） - correctionField of Follow_Up
message（t1小于纳秒部分+C1） = t2-t1-[(t2 - t1) +(t4 - t3)]/2-(C1+C2)/2 -C1= t2-t1-(D+C1)

上式假设

t2 - t1 = D+C1 master到slave时延

t4-t3 = D+C2；slave到master时延

假设线路时延两个方向都相等，都是D，C1为master到slave增加的排队时间，C2为slave到master的排队时延；

所以最终offsetFromMaster = t2-t1-(D+C1)；也就是正好减去了master到slave的线路时延和排队时间。这样就消除了两个方向排队时间不对等带来的影响。

再看P2P TC（一步时钟）的情况：

如果收到Sync报文，记算Sync报文经过它时候花费的时间residence time（master到slave的方向的排队时间，记为C1），并放到correctionField，然后转发Sync报文
即使后续收到follow_up报文，直接转发，不做任何修改
Pdelay_Req 和Pdelay_Resp 报文，终结于P2P TC，也就是P2P TC使用这两个报文进行z按正常的链路时延测量，t3-t2放入Pdelay_Resp的correctionField。
另外，透明时钟还需要把计算得到的路径时延增加加到Sync报文的correctionField。此时correctionFiled里面的值为（路径时延+C1）

路径时延计算：

<meanPathDelay> = [(t4 − t1) − correctionField of Pdelay_Resp]/2 = [(t4 − t1) −(t3 − t2) ]/2

按照以上公式，可以计算出Master到透明时钟的路径时延meanPathDelay_1，和透明时钟到slave的路径时延meanPathDelay_2；

时钟偏差值计算：

t2-t1-<meanPathDelay_2> = <syncEventIngressTimestamp>（即t2） ─ <originTimestamp> （即t1）─
<meanPathDelay_2> ─ correctionField of Sync message（即meanPathDelay_1 + C1） = t2-t1-<meanPathDelay_2>-<meanPathDelay_1>-C1

可以看出，只有master时钟到slave时钟方向的排队时间C1参与了时间偏差值计算；所以消除了两个方向排队时间不一致的影响。

总结一下：

P2P TC，如下图所示，Clock A和ClockC分别是master和slave时钟，ClockB是透明时钟；ClockB会使用PeertoPeer的时延测量方法（PDelayReq和PDelayResp）测出A到B的时延X，同样，ClockC会测量出B到C的时延Y；同时作为透明时钟的ClockB，需要测量Sync消息路过它的时候的内部排队时间C1，然后把C1+X放到Sync或Follow_Up消息的correctionField；当Clock C收到Sync或Follow_Up消息后，可以通过以下等式计算出和class A的时间偏差。

timeoffset = t2-t1-Y-(X+C1) = t2-t1-(X+Y+C1)

所以X+Y+C1正好是Clock A到Clock C的路径时延。

E2E TC，如下图所示，Clock A时master，Clock C是 Slave，Clock B是E2E透明时钟。

ClockA和Clock C之间采用DelayReq-Resp测量机制，测量A和C之间的平均时延M。C1和C2分别是A->C和C->A方向的排队时延。 C1是通过Sync报文经过ClockB时候测量出来的，C2是DelayReq报文经过CLockB测量出来的；C1会放在Sync或Follow_Up消息的correctionField，C2会放在DelayResp的correctionField。当Clock C收到C1和C2后，可以计算出和主时钟的时间偏差。

假设A到C的时延是D+C1，C到A的时延是D+C2

平均路径时延M = （D+C1+D+C2）/2

考虑correctionField的取值后的平均路径时延M = (D+C1+D+C2)/2 - (C1+C2)/2 = D

可以看出，此时的平均路径时延M，去掉了C1和C2后的平均值；

而真正的A到C方向的路径时延应该是D+C1；

所以最终的TimeOffset = t2-t1 - M- C1 = t2-t1-D-C1 = t2-t1-（D+C1）

所以最终的TimeOffset只有C1的影响，没有了C2，消除了C2带来的误差；