PTP (Precision Time Protocol) is a protocol for clock synchronization in networks. When supported by hardware, PTP is able to achieve sub-microsecond accuracy, which is much higher than NTP. So PTP is widely used in scenarios that require high-precision clock synchronization, such as audio/video synchronization, Fintec, and industrial automation.

For the basic concepts of PTP, see this blog： https://cloudswit.ch/blogs/what-is-ptp-and-how-does-it-work/

Recently, we did some testing between the most common PTP implementations available today, Linux PTP, and the enterprise SONiC (AsterNOS) provided by Asterfusion. Hope this article will be informative for you in choosing a PTP implementation solution!

What is Linux PTP

In Linux, the implementation of the PTP protocol is called Linux PTP, which is based on the IEEE 1588 standard, the package includes ptp4l and phc2sys.

Ptp4l implements PTP boundary clocks and common clocks, and supports hardware and software time synchronization.

• Hardware time stamps are used to synchronize the PTP hardware clock with the master clock
• Software time stamps are used to synchronize the system clock with the master clock.

Phc2sys is used to synchronize the system clock to the PTP hardware clock (PHC) on the NIC.

More details can be found at: https://sourceforge.net/projects/linuxptp/

LinuxPTP Architecture

The linuxPTP architecture is divided into two parts: kernel space and user space. There are two hardware drivers, one is the PHY/MAC with an internal TSU localtime stamp unit, and the other is the PTP Hardware Clock with an internal counter called TOD (Time of Day). In order to use PTP, the kernel driver must support either software or hardware time stamping, as does the NIC.

Test result of Linux PTP(ptp4l) + Linux NIC

Here we did a test based on ptp4l and the Linux NIC, you can see: the synchronization accuracy is distributed within 1000ns(1μs), but there are unstable jumps with more than 8000ns（8μs）.

Without additional software tuning, it may be sufficient for personal experiments with certain requirements on time precision. However, in more demanding commercial scenarios and larger-scale PTP domains, we need to further optimize the PTP performance to meet the needs of services such as intelligent driving, 5G, industrial automation, etc.

What are PTP-optimized SONiC Switches

SONiC system’s architecture comprises of various modules that interact among each other through a centralized and scalable infrastructure.

Asterfusion leads the community in implementing PTP in SONiC and optimizing its performance on the Enterprise SONiC Distribution–AsterNOS. Here we show the PTP subsystems, and there is a ptp container that runs Linux PTP /ptp4l and interacts with RedistDB and hardware drivers. Additionally, it is compatible with multiple network management protocols such as RESTful API, RESTconf, Netconf for easy integration and better interoperability.

Read more about AsterNOS：https://cloudswit.ch/product/sonic-enterprise-distribution/

AsterNOS virtualization images for network simulators, please visit:

https://www.gns3.com/marketplace/appliances/asterfusion-vasternos

In the hardware side, this white box switch integrates a PTP module to help with IEEE1588 and Synchronous Ethernet (SyncE), and it is removable (such as the PoE switch shown below, and yes, it even has 2 built-in DPU modules). Additionally, all ports support PTP and this switch can be used as both Boundary Clock (BC) and Transparent Clock (TC).

Time offset test on PTP-optimized SONiC switches

Before testing, let’s quickly review how PTP is implemented and the key terms involved.

2 Synchronization Mechanism in PTP switches: One-step and two-step

The time offset and transmission delay are calculated from the clock based on T1, T2, T3, T4

The one-step clock uses Sync and Pdelay Resp to carry timestamp information without sending Follow-up. It interacts with fewer messages than the two-step mode and consumes less network bandwidth, but the timestamps sent are the estimated time of message delivery, which is not as accurate as the two-step mode.

The two-step clock uses Follow-up to carry the timestamp, and the timestamp sent is the actual sending time, which can improve the accuracy of PTP time synchronization. However, if you’re just buying PTP-enabled switches to integrate into your network, these are less important and it’s okay to mix the two modes.

PTP Delay Measurement Mechanism: E2E or P2P

The measurement mode used by all clock nodes within a PTP domain must be the same. If there is no transparent clock(TC) in the network (works by updating PTP messages to correct for time spent in the device), there is little difference. We need to choose between E2E TC or P2P TC according to the actual networking needs.

In E2E mechanism, the TC sends sync messages all the way through the network. In P2P, each device on the network exchanges peer-delay measurement messages. TC responds to the sync messages and then sends its own Sync message to the OC, and OC can add up all of the path delay and the residence time to come up with the total network delay.

E2E TC

P2P TC

The P2P mechanism is more suitable for mesh networking and allows for fast switching when a link fails, because the latency of each segment is calculated independently; E2E is suitable for chain networking and is more versatile because it allows the network to have ordinary switches (which do not support PTP).

Test result of PTP-optimized SONiC Switches: Within 20ns

By utilizing hardware acceleration and software algorithm optimization, the synchronization accuracy of Asterfusion PTP-optimized switches is distributed within 20ns, and the deviation results obtained from different delay measurement modes are almost the same.

Test1: E2E+onsStep

Test3: E2E+oneStep+syncE

Test2: E2E+twoStep

Test4: P2P+twoStep

4 Asterfusion PTP-optimized Switch Models Powered by Enterprise SONiC