April 19, 2024
  • Whereas deploying Precision Time Protocol (PTP) at Meta, we’ve developed a simplified model of the protocol (Easy Precision Time Protocol – SPTP), that may provide the identical stage of clock synchronization as unicast PTPv2 extra reliably and with fewer assets.
  • In our personal exams, SPTP boasts comparable efficiency to PTP, however with important enhancements in CPU, reminiscence, and community utilization.
  • We’ve made the supply code for the SPTP shopper and server out there on GitHub.

We’ve beforehand spoken in nice element about how Precision Time Protocol is being deployed at Meta, together with the protocol itself and Meta’s precision time structure.

As we deployed PTP into one in every of our knowledge facilities, we have been additionally evaluating and testing different PTP purchasers. In doing so, we quickly realized that we may eradicate lots of complexity within the PTP protocol itself that we skilled throughout knowledge middle deployments whereas nonetheless sustaining full {hardware} compatibility with our current tools.

That is how the thought of Easy Precision Time Protocol (SPTP) was born. 

However earlier than we dive underneath the hood of SPTP we must always discover why the IEEE 1588 G8265.1 and G8275.2 unicast profiles (right here, we simply name them PTP) weren’t an ideal match for our knowledge middle deployment.

PTP and its limitations

Extreme community communication

A typical IEEE 1588-2019 two-step PTPv2 unicast UDP circulate consists of the next trade:

Determine 1: Typical two-step PTPv2 trade.

This sequence repeats both in full or partly relying on the negotiation outcome. The trade proven is one in every of many doable combos. It might contain further steps resembling grant cancellation, grant cancellation acknowledgements, and so forth.

The frequency of those messages could differ relying on the implementation and configuration. After finishing negotiation, the frequency of some messages can change dynamically.

This design permits for lots of flexibility, particularly for much less highly effective tools the place assets are restricted. Together with multicast, it permits us to help a comparatively massive variety of purchasers utilizing both very previous or embedded units. For instance, a PTP server can reject the request or verify a much less frequent trade if the assets are exhausted.

This design, nevertheless, results in extreme community communication, which is especially seen on a time equipment serving numerous purchasers.

State machine

As a result of “subscription” mannequin, each the PTP shopper and the server should preserve the state in reminiscence. This strategy comes with the tradeoffs resembling:

  • Extreme utilization of assets resembling reminiscence and CPU.
  • Strict capability limits that imply multicast help is required for big numbers of purchasers.
  • Code complexity.
  • Fragile state transitions.

These points can manifest, for instance, in so-called deserted syncs – conditions the place the work of a PTP shopper is interrupted (both forcefully stopped or crashed). As a result of the PTP server didn’t obtain a cancellation signaling message it should preserve sending sync and followup packets till the subscription expires (which can take hours). This results in further complexity and fragility within the system. 

 There are further protocol design uncomfortable side effects resembling:

  • An virtually infinite Denial of Service Assault (DoS) amplification issue.
  • Server-driven communication with little management by the shopper.
  • Full belief within the validity of server timestamps.
  • Asynchronous path delay calculations.

In knowledge facilities, the place communication is usually pushed by tons of of 1000’s of purchasers and multicast isn’t supported, these tradeoffs are very limiting. 


True to its title, SPTP considerably reduces the variety of exchanges between a server and shopper, permitting for rather more environment friendly community communication.


Determine 2: Typical SPTP trade.

In a typical SPTP trade:

  1. The shopper sends a delay request.
  2. The server responds with a sync.
  3. The server sends a followup/announce.

The variety of community exchanges is drastically lowered. As a substitute of 11 totally different community exchanges as proven on Determine 1 and the requirement for shopper and server state machines at some point of the subscription, there are solely three packets exchanged and no state must be preserved on both aspect. Within the simplified trade, each packet has an essential function:

Delay request

A delay request initiates the SPTP trade. It’s interpreted by a server not solely as a regular delay request containing the correction subject (CF1) of the clear clock, but in addition as a sign to reply with sync and followup packets. Similar to in a two-step PTPv2 trade, it generates T3 upon departure from the shopper aspect and T4 upon arrival on the server aspect.

To tell apart between a PTPv2 delay request and a SPTP delay request, the PTP profile Particular 1 flag should be set by the shopper.


In response to a delay request, a sync packet can be despatched containing the T4 generated at an earlier stage. Similar to in a daily two-step PTPv2 trade, a sync packet will generate a T1 upon departure from the server aspect. Whereas in transit, the correction subject of the packet (CF2) is populated by the community tools.


Following the sync packet, an announce packet is straight away despatched containing T1 generated at a earlier stage. As well as, the correction filed from the Delay Request subject is populated by the CF1 worth collected at an earlier stage.  

The announce packet additionally incorporates typical PTPv2 info resembling clock class, clock accuracy, and so forth. On the shopper aspect, the arrival of the packet generates the T2 timestamp.

After a profitable SPTP trade, default two-step PTPv2 formulation for imply path delay and clock offset should be utilized:

mean_path_delay = ((T4 – T3) + (T2-T1) – CF1 -CF2)/2

clock_offset = T2 – T1 – mean_path_delay

After each trade the shopper has entry to the announce message attributes resembling time supply, clock high quality, and so on., in addition to the trail delay and a calculated clock offset after each trade with each server. And, as a result of the trade is client-driven, the offsets might be calculated at the very same time. This avoids a state of affairs the place a shopper is following a defective server and has no likelihood of detecting it.

Determine 3: Consumer following defective Time Server 2 based mostly on announce.


We are able to additionally present stronger reliability ensures through the use of multi-clock reliance.

In our implementation for precision time synchronization, we offer time in addition to a window of uncertainty (WOU) to the patron utility through the fbclock API. As we described in a earlier weblog publish on how PTP is being deployed at Meta the WOU relies on the remark of time sync errors for the minimal length to have stationarity of the state of the system. 

As well as, we’ve established a way based mostly on a set of clocks that every shopper can entry for timing info that we name a clock ensemble. The clock ensemble operates in two modes, regular state and transient; the place regular state is throughout regular operation and transient is within the case of holdover.

Nevertheless, with a pool of N clocks, C, forming the clock ensemble, the query turns into which clocks to pick out for figuring out robustness and correct timing info. Clocks that aren’t correct are rejected (C_reject) and, thus, our ensemble measurement falls to N = C_total –  C_reject. We make use of two phases, one that’s based mostly on every particular person clock, and the second that acts on the gathering of legitimate clocks within the ensemble. 

The primary stage observes the earlier measurements of every particular person clock, the place the principle standards is to reject outliers within the earlier states of the clock. As soon as this criterion threshold is exceeded, your complete clock is rejected from the legitimate clock ensemble pool. That is based mostly off Chauvenet’s criterion, the place the criterion is a chance band that’s centered on the imply of the clock outputs (assuming a standard distribution throughout regular state). Based mostly on the stationarity exams, we use a pattern measurement of 400 earlier clock outputs and calculate a most allowable deviation. 

For instance:

, the place is the present clock output,  is the clock pattern imply, and is the clock set commonplace deviation.

We discover the chance that the present clock output is in disagreement with the earlier 400 samples:

Based mostly on a window measurement of 400 earlier samples, the utmost allowed deviation is:

Now, the clock outputs are examined in opposition to this worth. In the event that they exceed the  they’re rejected, an alert is raised, and a threshold counter is incremented. As soon as the rejection threshold is reached for a person clock, this clock is totally rejected.

Now, we enter the second stage of verifying the clock ensemble composed of the legitimate clocks. The second stage kinds a weighted common of the non-rejected clocks within the legitimate clock ensemble, the place every clock within the ensemble is reported as its pattern measurement, imply, and variance. The common of the clocks’ means is the weighted common, the place the weights are inversely proportional to the imply absolute deviations reported by every clock after making use of Chauvenet’s criterion. 

Now we will report the imply and variance of the clock ensemble, making certain the clocks contained therewith are legitimate and never offering inaccurate values. The boldness interval is scaled with the variety of good clocks within the ensemble, the place the upper the variety of legitimate clocks out of the full clocks gives higher reliability.

For numerous hosts, we present that the distribution of clocks falls inside the following heatmap:

Determine 4: Offset distribution overlay of a number of clocks.

We calculate the variance, , of every particular person clock’s observations, then we calculate a weighted imply, , making an allowance for the reciprocal of every clock’s variance as the load.

Resulting from independence of clocks, the variance of the weighted sum, , is:

In abstract, we gather samples from numerous clock sources that type our clock ensemble. The general precision and reliability of the offered knowledge by SPTP is a perform of the variety of dependable and in distribution clocks forming the clock ensemble.

A future publish will deal with this particularly. 

SPTP’s efficiency

Let’s discover efficiency of the SPTP versus PTP.

Preliminary deployments to a single shopper confirmed no regression within the precision of the synchronization:

Determine 5: Clock offset after switching from ptp4l and SPTP.

Repeating the identical measurement after migration to SPTP produces a really comparable outcome, solely marginally totally different resulting from a statistical error:

Determine 6: P99.99 offset collected from over 100000 SPTP purchasers.

With large-scale deployment of our implementations, we will verify useful resource utilization enhancements.

We seen that as a result of distinction in multi-server help, the efficiency positive factors differ considerably relying on the variety of tracked time servers.

For instance, with only a single time equipment serving your complete community there are important enhancements throughout the board. Most notably over 40 % CPU, 70 % reminiscence, and 50 % community utilization enhancements:

Determine 7: Packets per second with ptp4l (inexperienced) vs SPTP (blue).

The following steps for SPTP at Meta

Since SPTP can provide the very same stage of synchronization with rather a lot fewer assets consumed, we predict it’s an inexpensive different to the prevailing unicast PTP profiles.

In a large-scale knowledge middle deployment, it might assist to fight often altering community paths and create financial savings by way of community visitors, reminiscence utilization, and variety of CPU cycles.

It’s going to additionally eradicate lots of complexity inherited from multicast PTP profiles, which isn’t essentially helpful within the trusted networks of the fashionable knowledge facilities.

It must be famous that SPTP will not be appropriate for techniques that also require subscription and authentication. However this might be solved through the use of PTP TLVs (type-length-value). 

Moreover, by eradicating the necessity for subscriptions, it’s doable to look at a number of clocks – which permits us to offer larger reliability by evaluating the time sync from a number of sources on the finish node.

SPTP can provide considerably less complicated, quicker, and extra dependable synchronization. Much like G.8265.1 and G.8275.2 it gives wonderful synchronization high quality utilizing a unique set of parameters. Simplification comes with sure tradeoffs, resembling lacking signaling messages, that customers want to pay attention to and determine which profile is the most effective for them.

Having it standardized and assigned a unicast profile identifier will encourage wider help, adoption, and popularization of PTP as a default exact time synchronization protocol.

The supply code for the SPTP shopper and the server could be accessed on our GitHub page.


We want to thank Alexander Bulimov, Vadim Fedorenko, and Mike Lambeta for his or her assist implementing the code and the maths for this text.