https://blog.csdn.net/as480133937/article/details/105026033

https://blog.csdn.net/qq_40807206/article/details/120751119

 

【时间同步】IEEE-1588总结

锤王马加爵

于 2021-10-13 20:17:05 发布

3726
收藏 72
分类专栏: 通信网络与交换技术专栏 文章标签: 时间同步 IEEE1588 计算机网络
版权

通信网络与交换技术专栏
专栏收录该内容
1 篇文章1 订阅
订阅专栏
文章目录
第一章 计算机网络时间同步的意义
1.1 网络时间协议简介
1.2 网络时间协议的应用
第二章 PTP时钟同步模型
2.1 PTP系统
2.2 PTP设备类型
2.2.1 普通时钟(Ordinary clocks,OC)
2.2.2 边界时钟(Boundary clocks,BC)
2.2.3 透明时钟(Transparent clocks,TC)
2.2.4 管理节点(Management nodes)
2.3 IEEE-1588设备应用
2.4 PTP同步过程概述
2.4.1 E2E链路同步机制
2.4.2 P2P链路同步机制
2.4.3 总结
第三章 PTP报文格式
3.1 PTP报头结构
3.2 PTP报头主体
第一章 计算机网络时间同步的意义
1.1 网络时间协议简介
网络时间协议,即Network Time Protocol(NTP)是用来使计算机时间同步化的一种协议,它可以使计算机对其服务器或时钟源(如石英钟,GPS等等)做同步化,它可以提供高精准度的时间校正(LAN上与标准间差小于1毫秒,WAN上几十毫秒),且可介由加密确认的方式来防止恶毒的协议攻击。NTP的目的是在无序的Internet环境中提供精确和健壮的时间服务。
NTP提供准确时间,就需要有准确的时间来源,这一时间应该是协调世界时(UTC)。 NTP获得UTC的时间来源可以是铯原子钟、天文台、卫星,也可以从Internet上获取。

1.2 网络时间协议的应用
有很多应用依赖计算机间准确的时间才能运作正常,如果计算机间的时间误差比较大,这些应用和协议就可能完全失败。
例如,网络文件系统(NFS)是一个依赖时间的网络应用,它完全依赖各个工作站给服务器上的文件提供时间戳。当一个文件被创建或者被修改了,终端工作站的时钟被作为时间戳加在文件上。因此,如果客户端的时钟不同于服务器的时钟,则文件的时间戳将有不同。很多应用,从磁盘备份到生成程序都使用时间戳来确定哪个文件是最新的。在这种情况下,错误的时间戳意味着重大的文件损失,也就是工时和机时的损失。
又如,计算机程序员经常需要“make”工具来编译代码生成软件应用程序,“make”工具完全依赖各个文件的时间戳来确定哪个文件最近被修改了,随后决定哪个文件需要重新生成。如果“make”程序在一个分布式文件系统中应用,比如NFS,一台终端标记的时间戳和其它终端标记的会有不同,除非时钟是同步的。如果两台终端的时间不一致,这时运行“make”就会发生严重的错误。对于有些“make”程序,允许的时间偏差可以大一些,但是从典型意义上来说,与单独一次编译差不多,这段时间对于今天的计算机来说只不过是几秒钟而已。
再举个生活中的例子,在无人机集群表演中,成百上千架无人机的动作整齐划一,其中就仰仗了GPS授时和网络时间同步,才能让每架无人机在相同的时间节点同步做出规划好的动作。可以想象,如果没有时间同步技术,那么无人机表演将会是一幅多么混乱的画面。

第二章 PTP时钟同步模型
2.1 PTP系统
PTP 系统是由 PTP设备和非PTP设备组合组成的分布式网络系统。PTP与NTP的区别在于,NTP基于软件实现而PTP基于硬件(或者说是软硬协调)来实现。PTP系统的同步精度远大于NTP系统,常用在时间同步精度要求较高的应用场合。
PTP设备包括普通时钟(OC)、边界时钟(BC)、端到端透明时钟(E2ETC)、对等透明时钟(P2PTC)和管理节点。 非 PTP 设备包括网桥、路由器和其他基础设施设备,也可能包括计算机、打印机和其他应用程序设备等设备。
该协议是一种分布式协议,它规定了系统中的实时时钟如何相互同步。 这些时钟被组织成一个主从同步层次结构,层次结构顶部的时钟⎯主时钟⎯确定整个系统的参考时间。 同步是通过交换 PTP 定时消息来实现的,从设备使用定时信息将它们的时钟调整到层次结构中它们的主设备的时间。
PTP 系统中的设备通过通信网络相互通信。 网络可以包括实现不同网络通信协议的段之间的转换设备。
该协议在称为PTP域的逻辑范围内执行。 除非另有说明,所有 PTP 消息、数据集、状态机和所有其他 PTP 实体始终与特定域相关联。 给定的物理网络和连接到网络的单个设备可以与多个域相关联。 在该标准中,协议在一个域内建立的时间与其他域中的时间无关。

2.2 PTP设备类型
PTP 设备有五种基本类型:
a) Ordinary clock
b) Boundary clock
c) End-to-end transparent clock
d) Peer-to-peer transparent clock
e) Management node
PTP 中使用两种机制来测量 PTP 端口之间的传播延迟。 第一个,延迟请求-响应机制,使用消息 Sync、Delay_Req、Delay_Resp,如果需要,还使用Follow_Up。第二个是对等延迟机制,使用消息 Pdelay_Req、Pdelay_Resp,如果需要,还使用 Pdelay_Resp_Follow_Up。
普通时钟和边界时钟上的端口可以使用任何一种机制来实现。 端到端透明时钟上的端口独立于这些机制。 对等透明时钟上的端口使用对等延迟机制。 这两种机制不会在同一通信路径上互通。 此外,对等延迟机制仅限于每个对等端口与最多一个其他此类端口通信 PTP 消息的拓扑。

2.2.1 普通时钟(Ordinary clocks,OC)
在一个域中,维护着域内使用的时标,并且只有一个PTP端口的时钟。普通时钟要么作为主时钟提供时钟源,要么作为最末一级终端,从其他的时钟源获取时钟,而不能作为中间节点把时钟向其他节点传递。

2.2.2 边界时钟(Boundary clocks,BC)
边界时钟有多个PTP物理通信端口和网络相连,其每个PTP端口和普通时钟的PTP端口是一样的,其中的一个端口在收到上级时钟源的PTP报文后进行终结,然后再生成新的PTP报文并向下传递。

2.2.3 透明时钟(Transparent clocks,TC)
透明时钟作为中间节点,收到PTP报文之后不进行终结,其内部有一个驻留时间桥来计算报文在本节点的驻留时间,并以此来修正时间标签再向下传递。

透明时钟可分为E2E(End to End)透明时钟,以及P2P(Peer to Peer)透明时钟。两者对于PTP报文时延的修正和处理方法不同,在其他方面是完全一样的。

E2E透明时钟对时延的修正只包含本节点驻留的时间,而P2P透明时钟对时延的修正除了包含本节点驻留的时间之外,还添加了传输路径上的时延。

2.2.4 管理节点(Management nodes)
除了上述的几种时钟设备之外,IEEE1588-v2还定义了管理节点。管理节点负责处理PTP管理报文,有一个或者多个物理接口连接网络,可以和任意的时钟类型组合在一起工作。

2.3 IEEE-1588设备应用
全网支持IEEE1588-v2功能(FTS,Full Timing Support),是指主时钟和从时钟之间的所有传输设备都支持1588功能,包括边界时钟(BC模式)和透明时钟(TC模式)两种模式。它们的物理拓扑基本相同,仅在PTP协议的处理机制上有所差异。
边界时钟模式(BC模式)下的网络中间节点设备有多个1588端口,其中一个端口作为从时钟和上级时钟保持同步,其他端口则作为下一级网元的主时钟。设备收到1588v2报文之后进行终结,然后生成新的报文再向下游传递。

透传时钟(TC模式)下的网络节点设备接收到来自时钟源的1588v2报文之后不进行终结,而是根据报文的驻留时间和链路时延,修正报文的时间戳信息,并将其传送给下游设备。

2.4 PTP同步过程概述
2.4.1 E2E链路同步机制

E2E同步机制又称延时请求响应机制。上图是1588标准中E2E同步机制的原理图。不难理解,两个网络设备要靠网络报文来交换时间信息完成时间同步,而这些网络报文的发送和接收都会记录对应的时间戳。可以是软件的时间戳,也可以是硬件的时间戳,如MAC时间戳或者PHY时间戳。
同步消息交换的过程如下:
a) 主机向从机发送 Sync 消息并记录它发送的时间t1。
b) 从机接收Sync消息并记录接收时间t2。
c) 主机通过以下方式向从站传送时间戳t1:
1) 在Sync消息中嵌入时间戳t1。这需要某种硬件处理以获得最高的准确度与精度(单步模式)。
2) 在 Follow_Up消息中嵌入时间戳t1(双步模式)。
d) 从机向主机发送 Delay_Req 消息,并记录它发送的时间t3。
e) 主机收到 Delay_Req 消息并记录接收时间t4。
f) 主机通过将时间戳t4嵌入到Delay_Resp消息中来将时间戳t4传达给从机。

在此消息交换结束时,从机拥有t1~t4总共4个时间戳。这些时间戳可用于计算从时钟相对于主时钟的偏移量以及两个时钟之间消息的平均传播时间,在上图中是t-ms和t-sm的平均值。
偏移量和传播时间的计算假设主机到从机和从机到主机的传播时间相等(这个假设是1588协议的基础)。传播时间的任何不对称都会在时钟偏移的计算值中引入错误。由于不对称,计算出的平均传播时间与实际传播时间不同,也就是同步报文双向传输时产生的延时抖动会影响1588的同步精度。
由此得到平均传播延时Delay的计算公式如下:

从机相对于主机的时钟偏移量Offset的计算公式如下:

那么从机获取到自己的时钟相对于主时钟的偏移后如何调整自己的时钟呢?
从1588标准的角度,计算出offset已经完事了。1588协议本身并不规定怎么调整slave的时钟和master同步。但支持1588协议的软件通常会这么做,slave如果计算出和master的时间偏差,并且发现这个时间偏差超出设定的一个阈值,比如1ms,它就是直接重置clock的时间和master的时间值一样。
这样时间同步就完成了吗?并不是,因为重置时钟的过程是通过中断来完成的,而中断的调用是有延迟的,所以slave和master仍然时间会有偏差。而且如果这两个时钟在校准完毕后各自free running的话,他们之间的时间漂移仍然会越来越大。这个时候软件通常在重置slave clock之后,时间偏差小于设定阈值的情况下,用PI闭环算法来不断补偿slave的频率,使得计算得到的时间偏差趋于一个最小的稳定的数值。
如下图所示,重置完时钟(时间偏差小于阈值)后,PTP协议引擎周期性地采样与master间的时间偏移,并输入给PI控制器,由PI控制器的输出来调整本地内核PLL的频率,达到闭环缩小与主时钟的时间偏移的目的。当然,PI控制器对非线性系统的控制效果不高,实际使用中可能更换为效果更好的伺服算法。

2.4.2 P2P链路同步机制

P2P同步机制又称对等延时机制。上图为1588中P2P同步机制的原理图。在前面的E2E同步模式下,只能由主时钟端发起同步报文然后从时钟响应,而在P2P同步模式下,所有时钟端一视同仁,不分主从时钟,任何端口都可以发起P2P同步报文来主动获取链路延迟信息。
同步消息交换的过程如下:
a) 发起端发送报文Pdelay_req,并记录发送时间戳t1。响应端收到后,记录接收时间戳t2。
b) 响应端立即回复报文Pdelay_resp,把t2写在Pdelay_resp报文上,告诉发起端。同时记录发送时间戳t3。
c) 发起端收到Pdelay_resp,记录接收时间戳t4。
d) 紧随Pdelay_resp报文,响应端又发送一个叫作Pdelay_resp_follow_up的报文,将t3写在该报文上,告诉发起端。
然后,端口1使用这t1~t4共4个时间戳来计算平均链路延迟。

由此得到平均传播延时Delay的计算公式如下:

发起端相对于响应端的时钟偏移量Offset的计算公式如下:

2.4.3 总结
P2P同步机制是利用延时请求Pdelay_Req报文、延时回答Pdelay_Resp报文和可能的Pdelay_Resp_Follow_Up报文,计算两个支持P2P机制的通信端口之间测量端口到端口的传播时间,也就是路径延时。
与E2E同步机制相比,路径延时测量原理并无不同,只是路径延时测量在每段链路之间进行,主从节点间每段链路的链路延时累计在Pdelay_Resp或Pdelay_Resp_Follow_Up报文中,向下游传递,同时传递信息还包括同步报文在透明时钟TC上的驻留时间。从节点每段链路的链路延时和在透明时钟TC上的驻留时间,计算主从节点的平均路径延时。
但为什么已经有了E2E同步机制,还需要P2P同步机制呢?
根据2.4.1小节的E2E同步机制中的两个公式联立可以得到从机相对于主机时钟偏移量的另一个表达形式:

推出:

可见,想让从机获得自己相对于主机时钟的偏移量需要知道主从节点的整个平均路径延迟Delay和主机给从机发送Sync报文的两个时间节点t1和t2。
当一对主从时钟设备的路径通过一个E2E交换机,所有的报文经过交换机时,交换机将会将报文的驻留时间累加到报文的校正域中,但是路径的延时信息并没有事先知道,这就需要发送Sync报文和Delay_Req报文计算路径延迟,而E2E模式下的主时钟端就需要响应所有从机的Delay_Req报文,导致网络规模受到限制。
当一对主从时钟设备的路径通过一个P2P交换机时,在主机发送Sync报文之前,支持P2P模式的交换机会主动发起pDelay_Req报文,获取了交换机每个端口和与它们连接的端口间的路径延迟,并保存下来,当网络拓扑关系变化时,也能讯速地获取到新的路径延迟。因为路径延迟信息已经提前获得,主机只需要广播Sync报文和Follow_Up报文,而不需要响应所有从机的Delay_Req报文,网络的负荷大大降低了。Sync报文和Follow_Up报文经过P2P交换机时,驻留时间会累加到报文校正域中,而路径延迟已经提前获得,因此主机只需发送单向报文即可完成同步。

第三章 PTP报文格式
PTP-v2报文由报头(Header)、主体(Body)和后缀(Suffix)构成,其中后缀的长度可能为0。

3.1 PTP报头结构

messageType字段:报文类型,不同值代表不同PTP报文,含义如下:

versionPTP字段:PTP版本,v2就填0x2。
messageLength字段:构成PTP报文的八位字节总数,从报头开始到后缀都算。
domainNumber字段:PTP域序列号,
flagField字段:标志域,含义如下:

flagField字段第一个八位字节的Bit1(twoStepFlag)为双步标志,置1表示之后有跟随报文,清0表示为单步模式。
correctionField字段:修正域,传送透明时钟的驻留时间、P2P透明时钟的链路延迟以及非对称补偿。校正字段是以纳秒为单位测量的校正值乘以 216。例如,2.5 ns 表示为 000000000002800016。该字段所有位都是1(除非它就是这个数)代表校正值太大无法表示。校正字段的值取决于下表中描述的消息类型。

sourcePortIdentity字段:源端口号,发送端口的相关属性。
sequenceId字段:序列号,为了区分多条发送端口相同的同一类型的报文。
controlField字段:控制域,controlField的值取决于messageType字段中定义的消息类型,并且应具有下表中指定的值。不推荐接收者使用该字段。

logMessageInterval字段:对数报文时间间隔,logMessageInterval 字段的值由消息的类型决定,并应下表中所定义。包括发送声明报文的对数时间间隔,发送同步报文的对数时间间隔,发送延迟请求响应报文的对数时间间隔,它们的值是以2为底取的对数。

3.2 PTP报头主体
Sync报文和Delay_Req报文:

两种报文具有相同的报文主体,originTimeStamp 时间戳都是由历元,秒数和纳秒数构成的80bits时间戳信息。

Follow_Up报文:

Delay_Resp报文:

Pdelay_Req报文:

Pdelay_Resp报文:

Pdelay_Resp_Follow_Up报文:

————————————————
版权声明:本文为CSDN博主「锤王马加爵」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qq_40807206/article/details/120751119

原文地址:http://www.cnblogs.com/e-shannon/p/16876532.html

1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长! 2. 分享目的仅供大家学习和交流,请务用于商业用途! 3. 如果你也有好源码或者教程,可以到用户中心发布,分享有积分奖励和额外收入! 4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解! 5. 如有链接无法下载、失效或广告,请联系管理员处理! 6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需! 7. 如遇到加密压缩包,默认解压密码为"gltf",如遇到无法解压的请联系管理员! 8. 因为资源和程序源码均为可复制品,所以不支持任何理由的退款兑现,请斟酌后支付下载 声明:如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性