PTP: Precision Time Protocol as an NTP Alternative for Sub-Millisecond Accuracy

1. Why NTP Is Not Enough for Some Use Cases

NTP synchronizes system clocks across the internet or a local network usually to within a few milliseconds, and in well configured local networks with chrony even down to low double digit microseconds. For the vast majority of administrative tasks, from log timestamps to TLS certificate checks, this accuracy is entirely sufficient. There are, however, application classes where even a few microseconds of deviation are business critical or technically unacceptable.

A high frequency trading system needs to be able to reconstruct the exact order of market events across multiple servers, which requires timestamps with nanosecond accuracy. Distributed databases with external consistency, for example systems relying on globally synchronized timestamps for conflict resolution, likewise need far tighter time windows than NTP can deliver. Telecommunications networks, especially 5G base stations with time slot multiplexing, often require sub-microsecond accuracy between neighboring network elements under industry standards.

Exactly for these cases, PTP, the Precision Time Protocol under IEEE 1588, exists. While NTP is based on software timestamps that are inevitably noisy due to operating system latencies and network stack delays, PTP uses hardware timestamping directly inside the network card, eliminating most of these sources of uncertainty. The difference between NTP and PTP is therefore less a difference in algorithm than a difference in where in the network stack the timestamp is actually generated.

2. How PTP Works: Hardware Timestamping and Boundary Clocks

The fundamental difference between NTP and PTP lies in where the timestamp is generated. With NTP, the timestamp for an outgoing packet is created in the application or the operating system kernel, long before the packet actually leaves the physical network card. This delay between timestamp generation and actual transmission is variable and depends on current system load, introducing an unavoidable uncertainty into the measurement. PTP moves timestamp generation directly into the network card hardware, to the point where the packet physically leaves or arrives at the medium, removing operating system jitter from the measurement entirely.

A PTP domain organizes itself in a hierarchy: a grandmaster clock, usually connected to a GNSS antenna such as GPS, forms the highest accuracy time source. Boundary clocks, typically integrated into network switches, synchronize with the grandmaster clock and pass the time on to downstream segments, minimizing accuracy loss across multiple network hops. End devices, so called ordinary clocks, finally synchronize with the nearest boundary clock or directly with the grandmaster clock if no PTP capable switch sits in between.

The message exchange itself follows a four way handshake called the delay request response mechanism: sync and follow up messages flow from master to slave, delay request and delay response messages flow back, allowing both directions of network latency to be measured and the offset between the two clocks to be calculated precisely. This symmetric measurement, however, assumes that the forward and return paths actually have similar latencies, an assumption that can introduce additional sources of error in asymmetric network topologies.

3. Installing linuxptp: ptp4l and phc2sys

The reference implementation of PTP on Linux is called linuxptp and consists at its core of two programs: ptp4l synchronizes the network card's hardware clock, the so called PTP hardware clock, with the PTP network, while phc2sys subsequently aligns this hardware clock with the operating system's system clock. This split into two steps is deliberate, since not every network card has its own hardware clock, and software timestamping is also supported as a fallback, albeit with lower accuracy.

Installation on most Debian and Ubuntu systems happens via the package manager, RHEL based systems ship the package under the same name. After installation, a first check of the network card's capabilities is essential, since hardware timestamping is not supported by every network card, more on that in the following section.

#!/usr/bin/env bash
# Install linuxptp and verify the binaries are available
set -euo pipefail

apt-get update -qq
apt-get install -y linuxptp

# Confirm both core binaries are present
which ptp4l
which phc2sys

ptp4l --version

4. Configuring a PTP Domain on the Local Network

Configuring ptp4l happens via a configuration file, usually /etc/linuxptp/ptp4l.conf, where global settings as well as per interface settings are defined. The most important global parameters are the PTP domain number, which separates several independent PTP networks on the same physical network from each other, and the transport protocol, where UDPv4 is the common choice for most standard Ethernet networks, while Layer 2 transport is common in specialized industrial networks.

For a simple local setup with one server as the grandmaster clock and additional servers as slaves, an identical configuration file on all participants is sufficient, since ptp4l automatically negotiates which of the participating clocks acts as master via the Best Master Clock algorithm, based on configurable priority and quality values. A server with a GPS disciplined clock should be preferred as master through a lower priority1 value, since lower values mean higher priority in the Best Master Clock algorithm.

# /etc/linuxptp/ptp4l.conf — minimal single-domain configuration
[global]
domainNumber          0
priority1             128
priority2             128
# Lower priority1 value wins the Best Master Clock election
# A GPS-disciplined server would use e.g. priority1 = 10

# Prefer hardware timestamping when the NIC supports it
time_stamping         hardware

# Standard transport for typical Ethernet networks
network_transport     UDPv4

[eth0]
# Interface-specific overrides go under a section named after the NIC

5. Hardware Timestamping: Checking Network Card Requirements

Not every network card supports hardware timestamping, and without this support PTP loses most of its accuracy advantage over NTP. The command ethtool -T interface shows which timestamping modes a network card supports: HWTSTAMP_TX_ON and HWTSTAMP_FILTER_PTP_V2_L4_EVENT in the output indicate working hardware timestamping for PTP packets. Server network cards from Intel, particularly the 82599 and X710 series, and many Broadcom chipsets in data center hardware support this feature by default, while cheap consumer network cards often do not implement it at all.

If hardware timestamping is missing, ptp4l automatically falls back to software timestamping, which keeps PTP functional but significantly less precise, in practice often not much better than a well configured NTP installation with chrony. For environments where sub-microsecond accuracy is actually needed, checking network card compatibility beforehand is therefore the most important first step, even before the actual ptp4l configuration.

#!/usr/bin/env bash
# Check whether a network interface supports PTP hardware timestamping
set -euo pipefail

readonly IFACE="eth0"

# Look for hardware timestamping capability flags
ethtool -T "$IFACE"

# Expected relevant lines in the output:
# Hardware Transmit Timestamp Modes:
#     off
#     on
# Hardware Receive Filter Modes:
#     none
#     ptpv2-event
#     ptpv2-l4-event

# If only "off" and "none" appear, the NIC lacks hardware timestamping
# support, and ptp4l will fall back to less precise software timestamping.

6. phc2sys: Syncing the PTP Hardware Clock With the System Clock

ptp4l only synchronizes the network card's own PTP hardware clock, not the operating system's system clock, which applications continue to query via clock_gettime. phc2sys takes over exactly this second step: it continuously reads the PTP hardware clock and adjusts the system clock accordingly, either through gentle system clock frequency adjustment or, for larger initial deviations, through a one time jump at startup.

Calling phc2sys requires explicitly specifying which hardware clock serves as source and which as destination, usually the network card's PTP hardware clock as source and CLOCK_REALTIME, that is the system clock, as destination. In production environments, phc2sys runs as its own systemd service alongside ptp4l, with both services already preconfigured via the linuxptp package's systemd unit files and only needing adjustment to the actually used network card.

#!/usr/bin/env bash
# Start ptp4l and phc2sys together, syncing hardware clock to system clock
set -euo pipefail

readonly IFACE="eth0"

# Start ptp4l in the background, syncing the NIC's PTP hardware clock
ptp4l -i "$IFACE" -f /etc/linuxptp/ptp4l.conf -m &

# Wait briefly for ptp4l to establish a session with the master
sleep 5

# Sync the system clock (CLOCK_REALTIME) from the PTP hardware clock
phc2sys -s "$IFACE" -c CLOCK_REALTIME -w -m &

# Both should ideally run as systemd services in production:
# systemctl enable --now ptp4l phc2sys

7. Monitoring PTP: the pmc Tool and Offset Values

Monitoring a running PTP synchronization happens via the bundled pmc command, the PTP management client, which sends queries to the running ptp4l process over the protocol's management message channel. The most important value to query is the current offset to the master clock, output in nanoseconds, as well as the local clock's current role within the PTP hierarchy, that is whether it acts as master or slave.

A stable PTP setup with working hardware timestamping should show an offset in the low three digit nanosecond range or below, while growing or heavily fluctuating offset values point to network problems, missing hardware timestamping support, or an overloaded grandmaster clock. Beyond manual pmc queries, it is worth integrating the offset values into a monitoring system like Prometheus for continuous operation, to automatically detect long term trends and outliers instead of only noticing them during manual checks.

#!/usr/bin/env bash
# Query PTP synchronization status via the pmc management client
set -euo pipefail

# Current offset from master, in nanoseconds
pmc -u -b 0 'GET CURRENT_DATA_SET'

# Expected output includes a line like:
# offsetFromMaster       45
# meanPathDelay          612

# Query the local clock's role: MASTER, SLAVE, or PASSIVE
pmc -u -b 0 'GET PORT_DATA_SET' | grep -i "portState"

# Continuous monitoring loop for a health dashboard
while true; do
  offset="$(pmc -u -b 0 'GET CURRENT_DATA_SET' | grep offsetFromMaster | awk '{print $2}')"
  echo "$(date -u +%FT%TZ) offset_ns=${offset}"
  sleep 5
done

8. Typical PTP Use Cases

Financial trading systems are among the best known use cases for PTP, since regulations like MiFID II in the EU explicitly mandate microsecond level timestamp accuracy for high frequency trading venues, in order to document the exact order of transactions across multiple servers in a legally traceable way. Without PTP level accuracy, the order of two events happening within a few microseconds on different servers simply cannot be reliably reconstructed.

Distributed database systems with global consistency guarantees, relying on synchronized timestamps to resolve conflicts between concurrent writes, likewise benefit considerably from PTP level accuracy, since too large a time window between servers can lead to incorrect conflict decisions. In telecommunications, 5G base stations with time slot based multiplexing between neighboring radio cells require tight time synchronization to avoid interference at cell boundaries, which is why PTP profiles like ITU-T G.8275.1 were standardized specifically for mobile networks.

For the vast majority of web applications, Magento shops, and classic database setups, however, this level of accuracy is far beyond actual need, which is why PTP is rarely the right choice for standard hosting environments. A well configured chrony installation fully covers the practical requirements of these applications without the additional hardware and configuration effort of PTP.

9. NTP vs. chrony vs. PTP Compared

The following table compares the three most common time synchronization approaches on Linux to make the right choice easier depending on accuracy requirements.

As a rule of thumb: chrony is the right choice for practically every administrative and web based application. PTP only pays off when a concrete regulatory requirement or a technical necessity exists in the microsecond or nanosecond range, and the required PTP capable network hardware is already in place or can be budgeted for.

10. Summary

PTP under IEEE 1588 achieves sub-microsecond to nanosecond accuracy by generating timestamps directly in the network card hardware, instead of relying on software timestamps in the operating system stack the way NTP does. ptp4l synchronizes the network card's PTP hardware clock with the PTP network, phc2sys takes over the second step and aligns the system clock with this hardware clock. Hardware timestamping support on the network card is a mandatory prerequisite for the full accuracy gain.

Typical use cases are financial trading systems with regulatory timestamp requirements, distributed databases with global consistency guarantees, and telecommunications networks with time slot multiplexing. For the vast majority of web applications and standard server operations, chrony remains the correct, far simpler to operate choice; PTP only pays off with concrete microsecond or nanosecond level needs.

11. FAQ: PTP on Linux