为什么要区分E2E和P2P？
PTP的核心目标是让网络中的所有时钟与最精确的时钟（Grandmaster Clock）同步。为了实现纳秒级的同步精度，PTP必须计算并补偿报文在网络中传输所产生的链路延迟（Link Delay）。
E2E和P2P就是两种计算这个链路延迟的不同方法。它们的根本区别在于：延迟计算的范围和由谁来计算。
E2E (End-to-End) 端到端延迟机制
延迟是从主时钟（Master） 到从时钟（Slave） 的整条路径上测量的。它计算的是这两个端点之间的总延迟。在这种机制中，普通时钟（Ordinary Clocks） 和透明时钟（Transparent Clocks） 必须支持E2E模式。
工作原理
- 路径延迟测量：主时钟和从时钟之间通过 Sync、Follow_Up、Delay_Req、Delay_Resp 报文交互，计算出它们之间的总路径延迟。
- 透明时钟的作用：网络中的E2E透明时钟（E2E-TC） 会侦听这些PTP报文。当它们转发报文时，会测量该报文在本设备内部的停留时间（驻留时间），并将这个时间值累加到一个专门的校正字段（correctionField）中。
- 从时钟的计算：从时钟最终收到报文时，会从报文的 correctionField 中获取所有经过的透明时钟的驻留时间之和。然后，它使用以下公式计算偏移：Offset = [(t2 - t1) - (总路径延迟)] / 2（其中 总路径延迟 = 计算出的链路延迟 + 所有透明时钟的驻留时间之和）
P2P (Peer-to-Peer) 点对点延迟机制
延迟是在每一段相邻的链路上，由两个直接相连的P2P设备之间单独测量的。它不是计算端到端的延迟，而是计算"跳"到"跳"的延迟。在这种机制中，边界时钟（BC） 和对等透明时钟（P2P-TC） 必须支持P2P模式。
工作原理
1**. 逐段延迟测量**：网络中的每一个支持P2P的设备（如P2P-TC或BC的每个端口），都会与它的直接上游邻居和直接下游邻居使用 Pdelay_Req、Pdelay_Resp、Pdelay_Resp_Follow_Up 报文进行交互，持续测量并维护它们之间这一段链路的延迟值。
2.传播时间校正：当主时钟发出的 Sync 报文经过一个P2P设备时，该设备会做两件事：
- a) 像E2E-TC一样，测量并累加报文在本设备的驻留时间到 correctionField。
- b) 再加上 从本设备到上游邻居设备的那段已经测量好的链路延迟，也累加到 correctionField 中。
**3. 从时钟的计算：**从时钟最终收到的报文的 correctionField 中，已经包含了从主时钟到它自己整条路径上所有设备的驻留时间和所有链路的延迟之和。从时钟无需再单独计算路径延迟，可以直接使用这个校正值来精确计算偏移。
LinuxPTP
在 Linux 中，PTP 协议的实现称为 Linux PTP，它基于 IEEE 1588 标准，软件包有 ptp4l 和 phc2sys。
我们基于 ptp4l 和 Linux 网卡做了测试，可以看到：同步精度分布在 1000ns（1μs）以内，并且存在 8000ns（8μs）以上的不稳定跳变。
在没有额外调优工作的前提下，这样的同步精度对于个人爱好者或一般实验环境或许足够，但离企业级商用场景还远远不够。
作为参考，此处列出 ITU（国际电信联盟）提出的时间同步能力分类，
- A类：时间误差≤50ns，适用于对同步精度要求较低的一般电信网络。
- B类：时间误差≤20ns，适用于更严格的时间同步场景，如5G基站同步。
- C类：时间误差≤10ns，主要用于对同步精度要求极高的场景，例如5G前传。
SONiC（AsterNOS） PTP
下图是AsterNOS 内的 PTP 子系统示意图，包含一个运行 Linux PTP / ptp4l 并与 RedistDB 和底层硬件驱动程序交互的 PTP 容器。此外这套系统还支持多种网络管理协议，例如 RESTful API、RESTconf 和 Netconf，给到更优的系统集成和互操作性。
通过硬件加速和软件算法优化的PTP 交换机的时间同步精度分布在 20ns 以内，并且不同延迟测量模式获得的偏差结果几乎相同。
- one-step：Sync 报文带报文发送时刻的时间戳
- two-step：Sync 报文不带报文发送时刻的时间戳，只记录本报文发送时的时间，由Follow_Up报文带上该报文发送时刻的时间戳。
CX-M 交换机产品已经系列化地支持了 PTP ，兼容 E2E 和 P2P 模式。
【更多详细内容，请访问 https://asterfusion.com/】