Handling time in a networked environment is never easy. The Network Time Protocol (NTP) has been used to synchronize clocks across the internet for almost 40 years — but, as computers and networks get faster, the degree of synchronization it offers is not sufficient for some use cases. The Precision Time Protocol (PTP) attempts to provide more precise time synchronization, at the expense of requiring dedicated kernel and hardware support. The Linux kernel has supported PTP since 2011, but the protocol has recently seen increasing use in data centers. As PTP becomes more widespread, it may be useful to have an idea how it compares to NTP.

PTP has several different possible configurations (called profiles), but it generally works in the same way in all cases: the computers participating in the protocol automatically determine which of them has the most stable clock, that computer begins sending out time information, and the other clocks on the network determine the networking delay between them in order to compensate for the delay. The different profiles tweak the details of these parts of the protocol in order to perform well on different kinds of networks, including in data centers, telecom infrastructure, industrial and automotive networks, and performance venues.

Choosing a clock

Each PTP device is responsible for periodically sending "announce" messages to the network. Each message contains information about the type of hardware clock that the device has. The different kinds of hardware clocks are ranked in the protocol by how stable they are, from atomic clocks and direct global navigation satellite system (GNSS) references, through oven-controlled thermal oscillators, all the way down to the unremarkable quartz clocks that most devices use. The device also sends out a user-configurable priority, for administrators who want to be able to designate a specific device as the source of time for a network without relying on the automatic comparison.

When a PTP device receives an announce message for a clock that is better than its own, it stops sending its own messages. Some PTP profiles require network devices to modify the announce messages received on one port in order to rebroadcast them to its other networks. This helps with larger networks that may not allow broadcast messages to reach every device. Other profiles are designed to work with commodity networking equipment, and don't assume that the messages are modified in transit. All of the PTP profiles do require the computers directly participating in PTP to have support for fine-grained packet timestamping, however. Eventually, only one clock on the network will still be sending announce messages. Once this happens, it can start being a source of time for the other clocks.

Determining the delay

Figuring out a good clock and using it as a time reference is more or less what NTP does. Where PTP gets its higher accuracy is from the work that goes into determining the delay between the reference clock and each device. The PTP standard defines two different mechanisms for that: end-to-end delay measurements and peer-to-peer delay measurements. The advantages of the former approach are that it measures the complete network path between the device and the reference clock, and works without special networking equipment along the path. The disadvantage is that it requires the reference clock to respond to delay-measurement requests from every PTP device on the network, and can take longer to converge because of network jitter.

Both mechanisms take the same basic approach, however: they assume that the network delay between a device and the reference clock is symmetrical (which is usually a safe assumption for wired networks), and then send a series of time-stamped packets to figure out that delay. First, the device sends a delay-measurement request and records the timestamp for when it was sent. Then the reference clock (for end-to-end measurements) or the network switch (for peer-to-peer measurements) responds with two timestamps: when the request was received, and when the response was sent. Finally, the device records when the response arrives. The two-way network delay is the elapsed time minus the time the other device spent responding; the one-way network delay is half of that.

There is one additional complication: how are devices supposed to send a response that includes the timestamp of the response itself? Generally, this requires either special hardware support from the network interface to support inserting timestamps into packets as they are sent, or it requires the use of multiple packets, where the second packet is sent as a follow-up message with the timestamp of the first. Delay measurements like this only work well when the networking hardware can report precise timestamps to the kernel for both packets sent and packets received.

In the peer-to-peer case, the peer device also sends its total calculated delay to the current reference clock. Generally, PTP devices will continuously measure the delay to the reference clock. Then, when receiving the time from the reference clock, the devices can add the delay as a correction. How well this works depends on the exact PTP profile used and the network topology, but it generally allows for much better accuracy than NTP.

Putting it together

During initial development of the protocol, PTP targeted "sub-microsecond" synchronization. In practice, with PTP-aware network hardware on a local network, the protocol can achieve synchronization on the order of 0.2µs. Over a larger network and without specialized hardware, an accuracy of 10µs is more typical. NTP generally achieves an accuracy of 200µs over a local network, or about 10ms over the internet. A PTP time source is not as good as a direct GNSS connection — which can provide synchronization on the order of 10ns — but on the other hand, it also does not require expensive analog signal processing or an antenna with a clear view of the sky.

No time-synchronization system is ever going to get clocks to agree perfectly, but having better synchronization can have important performance implications for distributed systems. Meta uses PTP in its data centers to limit the amount of time that a request needs to wait to ensure that distributed replicas are in agreement. The company claimed that the switch from NTP to PTP noticeably impacted latency for many requests. Having precisely synchronized clocks also enables time-sensitive networking — where traffic shaping decisions can be made based on actual packet latency — for networks that handle realtime communication.

PTP on Linux

Support for PTP in the kernel is mostly part of the various networking drivers that need to support precise timestamps and related hardware features. There is, however, a generic PTP driver that handles presenting a shared interface to user space. The driver doesn't handle actually implementing PTP, but rather just the hardware support and unified clock interfaces to allow user space to do so. Although most devices will only have to worry about one PTP clock at a time, the driver allows handling multiple clocks. Each clock can be used with the existing POSIX interfaces: clock_gettime(), clock_settime(), etc. So many applications will not need to change the way they interact with the system clock at all in order to take advantage of PTP. The exception is software that needs to know what the current time source is — for example, to determine how reliable the provided timestamps are. As of the upcoming 6.13 version, the kernel will also include support for notifying virtual machines when their time source changes due to VM migrations.

The Linux PTP Project provides a set of user-space utilities to actually implement the protocol itself. These include a standalone daemon, some utilities to directly control hardware clocks, and an NTP server that uses the PTP clock as a reference. The project makes it fairly simple to set up a Linux computer as a PTP clock — so long as the computer's networking hardware can produce sufficiently high-resolution timestamps. The documentation is a little sparse, but does include examples of how to configure the software for different PTP profiles.

PTP is unlikely to be deployed internet-wide, the way NTP is, because its automatic clock selection is a poor fit for an open network. It is also not as good as a direct satellite connection, or an on-premise atomic clock, for applications that need the most precise time possible. But for facilities that need to provide reasonably accurate time across many devices at once, it could be a good fit. As applications continue to demand better clocks and networking hardware with the necessary capabilities becomes more common, PTP may spread to other networks as well.