PTP,由IEEE 1588标准定义,是一种专门设计用于在分布式系统中通过网络(主要是以太网)同步时钟的协议。其核心目标是提供比NTP更高的时间同步精度。
如果NTP是让城市里的大钟楼(服务器)为市民的手表(客户端)提供大致准确的报时,那么PTP则更像是在一个精密的实验室或工厂车间里,用一套高度校准的仪器,确保每一个关键设备上的“秒表”都与中央的“原子钟”达到几乎完全一致。
在复杂的网络中,PTP消息可能会经过多个交换机。这些交换机如果不能正确处理PTP消息,就会引入额外的延迟,降低同步精度。为此,PTP定义了特殊的PTP感知交换机:
PTP实现高精度的核心在于其精密的测量机制和对网络延迟的细致处理。我们以常见的端到端 (End-to-End, E2E) 延迟请求-响应机制为例,来剖析PTP的“对表”艺术:
网络中所有PTP设备(时钟)通过交换Announce Message (通告消息),运行BMCA。
比较的依据包括用户配置的优先级 (Priority1, Priority2) 和时钟自身的质量参数 (ClockClass, ClockAccuracy, OffsetScaledLogVariance),最后以唯一的时钟身份 (ClockIdentity,通常基于MAC地址) 作为决胜局。
专业数据: Priority1/2是0-255的整数,越小越优先。ClockClass指示时钟的可追溯性,如6代表同步到GPS,248代表未同步。ClockAccuracy和OffsetScaledLogVariance则更细致地描述了时钟的精度和稳定性。
最终,网络中所有设备会一致地选举出一个最佳主时钟 (Grandmaster Clock, GM)。
GM开始周期性地向网络中的从时钟(Slave Clocks)发送Sync Message (同步消息)。
关键点: Sync消息中(或紧随其后的Follow_Up Message中)携带了GM发送该Sync消息的精确发送时间戳 t1
。
硬件时间戳的应用: 为了获得精确的t1
,这个时间戳必须在数据包即将离开GM网卡的物理层时由硬件捕获。(软件捕获会引入操作系统调度等不确定延迟。)
单步 vs. 两步:
t1
直接在Sync消息中。t1
。从时钟“接收并记录”:从时钟接收到Sync消息,同样在硬件层面记录下精确的接收时间戳 t2
。
从时钟向GM发送一个Delay_Req Message (延迟请求消息),并硬件记录其精确的发送时间戳 t3
。
GM接收到Delay_Req消息,硬件记录其精确的接收时间戳 t4
。
GM将t4
封装在Delay_Resp Message (延迟响应消息)中回复给从时钟。
从时钟集齐了t1, t2, t3, t4
四个关键时间戳。
核心假设:路径延迟对称 (Master到Slave的延迟 ≈ Slave到Master的延迟)。
MeanPathDelay = [(t2 - t1) + (t4 - t3) - correctionField_sum] / 2
(这里的 correctionField_sum
是Sync/Follow_Up和Delay_Resp消息中correctionField
字段的累加值,用于补偿路径上透明时钟引入的延迟)
OFM = (t2 - t1) - MeanPathDelay - correctionField_Sync
下图是企业级 SONiC 发行版AsterNOS内的 PTP 子系统示意图,包含一个运行 Linux PTP / ptp4l 并与 RedistDB 和底层硬件驱动程序交互的 PTP 容器。此外这套系统还支持多种网络管理协议,例如 RESTful API、RESTconf 和 Netconf,给到更优的系统集成和互操作性。
通过硬件加速和软件算法优化的 PTP 交换机的时间同步精度分布在 20ns 以内,并且不同延迟测量模式获得的偏差结果几乎相同。
资料参考:https://blog.csdn.net/shmexon/article/details/148761212
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。