Measuring the Accuracy of Simplified PTP Time Transfer

5 mins read

A measure of the elegance of a design is how well it stands the test of time and how well it can be adapted to changing needs. By this measure, David L. Mills had the most elegant of designs when he invented Network Timing Protocol (NTP). NTP has been adapted to the need for greater accuracy with Precision Timing Protocol (PTP) which is now enshrined in standard IEEE 1588. PTP, in turn, has been adapted to a number of use cases by using different profiles such as for Telecoms and industrial applications and even for sub-nanosecond synchronization applications with IEEE 1588-2019 Annex M (White Rabbit).

While it is robust and versatile, PTP has some overhead associated with things like handshakes, timers and subscriptions in networks that support unicast. The packet exchange sequence is shown below.

Meta (formerly known as Facebook) has recently developed a profile for PTP that takes advantage of the fact that in their Data Centers, they have a well-defined and homogeneous sync architecture using unicast packet exchange and transparent clocks in the network.

The diagram below shows the packet exchange sequence they use and comes from github at tree/main/ptp/sptp. The protocol is referred to as Simplified Unicast PTP, simple PTP or sPTP.

The Client sends a DELAY REQUEST packet to initiate an exchange with the Server. The Client records timestamp t3, while the Server records CorrectionField_2 (CF_2) from the DELAY REQUEST packet and the Rx timestamp t4. 

The Server then sends a SYNC packet adding timestamp t4 in the originTimestamp field, and records the Tx timestamp t1. The Server also sends an ANNOUNCE packet with the Tx timestamp t1 and CF_2 from the DELAY REQUEST packet. 

The Client records t2 of the received SYNC packet, plus CF_1. It also records data from the ANNOUNCE packet and CF_2. 

As a result of this exchange the Client has access to t1, t2, t3, t4, CF_1 and CF_2 to calculate mean path delay and offset metrics. 

In addition to the benefits including simple implementation, no Server-Client negotiation, Client-driven exchange, and low resource consumption, sPTP provides a potential bonus for network monitoring. This is the ability to centrally monitor the absolute time error for any remote Client.


To see how to monitor synchronization in a Data Center packet network, let’s take a look at the reference network diagram from the OCP Data Center profile.


Given the reduced resource required, there is the potential for each Server to implement both the sPTP timeReceiver and sPTP timeTransmitter functions. The Clients will issue DELAY REQUESTs to the Grandmaster and process the received SYNC and ANNOUNCE/ FOLLOW_UP messages to discipline their own clocks.

In addition, if transparent clocks and unicast packet exchange are used, the Server could also periodically respond to a monitoring device’s DELAY REQUEST with their own SYNC and ANNOUNCE/FOLLOW_UP messages using their own clocks for generating t1 and t4.

This holds the potential to solve the problem of how you verify the accuracy of the delivered time when there is no reference located at the timeReceiver other than the network-provided PTP time.

Here we see time being delivered to a Client from a Grandmaster via the red path while being monitored via the yellow path. A suitably powerful monitoring instrument could poll through all Clients periodically, comparing time domains and Grandmasters to ensure an accurate source of time and assuring network synchronization accuracy through continuous performance monitoring. Moreover, the monitoring instrument could be directed to specific devices based on indications of sync failure, probing network devices to check whether time synchronization has been maintained at various points in the network.

Learn more about the Sentry and Sentinel measurement solutions.