What is PTP? Precision Time Protocol explained

PTP (Precision Time Protocol) makes sure all clocks and devices on a network keep exactly the same time, down to a fraction of a millionth of a second. It is the precise big brother of NTP, the protocol that keeps ordinary computers and servers on time.

Why so precise?

In some environments "roughly equal" is not good enough. Think of a television studio where several camera feeds must run perfectly in sync, a trading system that has to stamp every transaction at the right moment, or a high-voltage substation that must locate a fault to the microsecond. That is where PTP is used.

How is that precision achieved?

Two things make the difference with NTP:

• The time is stamped by the network card itself, not by the computer's software. That avoids costly, unpredictable delay.
• Special network switches account for their own delay and correct it actively, so the time does not drift on the way.

One device on the network is the boss of the time: the grandmaster. It usually gets its time from satellites (GPS and related systems) and distributes it to all the other devices.

In short

Are milliseconds accurate enough? Then NTP is fine. Do you need microseconds or better? Then PTP is the answer. In doubt? We are happy to think along with you.

Precision Time Protocol (PTP), standardised in IEEE 1588, brings clock synchronisation down to the sub-microsecond level over an Ethernet network. Where NTP is enough for logging and TLS validation at the millisecond level, PTP demands deliberate choices in switches, oscillator and network architecture. This article explains when you need PTP, how the hierarchy works, and which profile fits your application.

PTP in 60 seconds

PTP uses a grandmaster clock that distributes its time to all other clocks on the network via a series of four timestamp exchanges per cycle. Two fundamental improvements over NTP account for the higher precision:

• Hardware timestamping on the Network Interface Controller (NIC) instead of in the OS software layer. That eliminates the jitter of the kernel scheduler.
• Network symmetry: PTP-aware switches actively correct for their own internal queue delay so that asymmetric delays are compensated.

According to Banerjee & Matsakis (2023), chapter 7.4, PTP achieves the following orders of magnitude depending on the application: financial trading requires ±100 µs, transportation ±10 µs, broadcast ±1 µs, telecom ±150 ns to ±3 µs, and power line fault detection ±100 to ±500 ns. With the White Rabbit high-accuracy profile, sub-nanosecond accuracy can be reached in lab environments.

PTP vs NTP: when do you pick which protocol?

The question "PTP or NTP" is an investment decision. PTP-aware switches cost a multiple of regular switches, and PTP grandmasters often require OCXO or Rubidium holdover.

	NTP	PTP (IEEE 1588)
Typical LAN accuracy	1 to 10 ms	100 ns to 1 µs
Hardware requirements	regular switches	PTP-aware switches (boundary or transparent clocks)
Timestamping	software (OS kernel)	hardware (NIC)
Symmetry requirement	no	yes, switches compensate own delay
Typical application	IT servers, clocks, logging	broadcast, finance, digital substation, 5G fronthaul

For a more extensive comparison: see our article NTP vs PTP.

How is the PTP hierarchy structured?

PTP defines four clock roles. Every second the network elects, via the Best TimeTransmitter Clock Algorithm (BTCA, formerly Best Master Clock Algorithm), which clock is grandmaster.

• Grandmaster clock: the source. Gets its time from GNSS or an atomic source. Distributes PTP time to the network. In Masterclock deployments this is typically a GMR6000 or NTP100-OSC.
• Boundary clock: has multiple ports and sits between two PTP networks. Receives PTP time on one port and retransmits on the others. Banerjee & Matsakis (2023, section 7.4): *"A boundary clock receives time from one network, and can serve as a source on a different network if the BTT algorithm calls for it."*
• Transparent clock: a PTP-aware switch or router that lets PTP packets through and adds a correction field for its own queue delay. Crucial for accuracy: a regular switch disturbs PTP, a transparent clock corrects.
• Ordinary clock: has a single port. Typically receives time, but can in principle become grandmaster if BTCA indicates that.

A warning from Banerjee & Matsakis (2023): *"Be careful that the component adds the delay as a pre-computed value rather than as a measurement, because the precision is significantly degraded when PTP-aware components compute this delay by taking the time to measure the ingress and egress epochs within software."* So ask your switch vendor explicitly how the transparent-clock correction is implemented, not just whether "PTP is supported".

What are PTP profiles and why do they exist?

IEEE 1588 defines the general protocol. But every industry has its own accuracy requirements, redundancy strategies and transport choices. For that reason there are profiles, predefined subsets of IEEE 1588 with fixed parameter choices.

• Default Profile (Annex J of IEEE 1588): generic implementation. Works everywhere, but is not optimised for specific industry requirements.
• Telecom Profile G.8275.1: full-timing support for mobile networks. Frequency and phase sync. Requires PTP-aware switches across the entire path. Used for 4G and 5G fronthaul.
• Telecom Profile G.8275.2: partial-timing support. Works over networks where not all switches are PTP-aware. Less accurate than G.8275.1, but more pragmatic in legacy deployments.
• Power Profile IEC 61850-9-3: PTP for digital substations in power grids. Requires boundary clocks, HSR and PRP redundancy and ±1 µs accuracy substation-wide.
• Power Profile IEEE C37.238: American variant of the power profile with a comparable goal. Many grandmasters support both at once.
• Media Profile SMPTE 2059-2: PTP for IP broadcast (replacing legacy SDI genlock). Part of the SMPTE ST 2110 suite for professional media over IP.
• Enterprise Profile: lighter alternative for IT networks that want more than NTP level accuracy without the operational overhead of Telecom or Power profiles.

Important: PTP equipment following different profiles is not interchangeable. Banerjee & Matsakis (2023, section 7.4) warn explicitly: *"PTP equipment following different profiles may not be compatible. The user is also warned that sometimes equipment from different manufacturers can prove incompatible even if they purport to follow the same profile."*

So choose the profile first (driven by your industry), and only after that the brand. For a deeper dive into the power-utility variants: see our article Power Profile: IEC 61850-9-3 vs IEEE C37.238.

What hardware do you need for PTP?

A PTP deployment depends on three hardware components that you must specify correctly.

PTP-aware switches

The referee between "real PTP" and "PTP on-paper". A regular gigabit switch passes PTP packets, but adds unpredictable delay. A PTP-aware switch is either a transparent clock (corrects its own delay) or a boundary clock (terminates PTP on the input side and regenerates on the output side). Both patterns work, with different trade-offs in scalability and troubleshooting.

Grandmaster oscillator

The internal oscillator of the grandmaster determines how well the network survives if GNSS drops out. Three families:

• TCXO: holdover of minutes to a few hours within ±1 ms. Suitable for IT applications, not for strict PTP.
• OCXO: holdover of 24 hours to a few days within ±1 µs. Standard for broadcast and industrial PTP deployments.
• Rubidium: holdover of weeks within ±1 µs. For defence, telecom fronthaul, financial trading with 24+ hour GNSS outage scenarios.

See our article Holdover sources: TCXO, OCXO and Rubidium compared for the detailed comparison.

GNSS antenna and disciplining

The grandmaster needs a GNSS source to periodically discipline the oscillator. Antenna choice, cable length and sky view are crucial, see our article GNSS disciplining: GPS, GLONASS, Galileo and BeiDou together.

Precision budget: what do you realistically achieve?

Every layer in the PTP path adds uncertainty. A rough rule of thumb, with the caveat that exact figures strongly depend on switch implementation, cable lengths and network load:

• Grandmaster, GNSS disciplined, OCXO: tens of ns to ±100 ns deviation from UTC
• PTP-aware switch (transparent clock): typically ±100 ns extra per hop
• End clock via boundary clock on the last segment: around ±1 µs total budget

Banerjee & Matsakis (2023, section 7.4) confirm: PTP applications typically achieve sub-microsecond precision as long as the entire chain is PTP-aware. Without PTP-aware components PTP falls back to NTP comparable accuracy.

Frequently asked questions

Do I need PTP, or is NTP enough?

For IT logging, TLS certificate validation and log correlation at the millisecond level, NTP is more than enough. PTP is needed as soon as you have requirements at sub-millisecond level: broadcast frame sync, financial trading (MiFID II), digital substations (IEC 61850), 5G fronthaul. A short rule of thumb: do you have milliseconds? NTP. Microseconds? PTP.

Does PTP work over WAN or the internet?

PTP is designed for controlled LAN environments. PTP does work on the internet, but loses its precision advantage over NTP because intermediate routers are not PTP-aware. Banerjee & Matsakis (2023) note that PTP without PTP-aware components is just as sensitive to variable paths as NTP. For WAN deployments: PTP within each site, NTP between sites, or consider White Rabbit for scientific applications.

What is the difference between end-to-end and peer-to-peer delay?

End-to-end (E2E) calculates the delay of a PTP packet across the entire path from grandmaster to slave in a single measurement. Peer-to-peer (P2P) calculates the delay per link between direct neighbours. P2P is more robust under network changes and is mandatory in Power Profile (IEC 61850-9-3). E2E is simpler and is the default in many other profiles.

What is White Rabbit and when is it relevant?

White Rabbit is a high-accuracy PTP profile that achieves sub-nanosecond accuracy through additional hardware (carrier-signal measurement in switches). Developed at CERN for particle-accelerator synchronisation. For commercial broadcast or finance it is overkill. For scientific applications, radio astronomy and quantum experiments it is the standard choice.

Can PTP and NTP run on the same network?

Yes, and in practice that happens often. A PTP grandmaster such as the Masterclock GMR6000 delivers PTP for mission-critical devices and NTP for the rest of the network at the same time. Place the PTP-aware switches on one branch segment for the PTP clients, and let NTP clients connect via regular switches.

Next step

View Masterclock master clocks that support PTP.