Key takeaways
- PTP (IEEE 1588) synchronises clocks across a network to sub-microsecond accuracy using hardware timestamps and two-way message exchanges.
- Trading needs precise time for regulation, latency measurement, order book reconstruction and best-execution evidence.
- MiFID II RTS 25 requires HFT firms to stay within 100 microseconds of UTC with 1-microsecond timestamp granularity; US CAT requires 50 milliseconds for members and 100 microseconds for exchanges.
- Accuracy depends on hardware timestamping, boundary or transparent clocks and a reliable grandmaster, usually disciplined by GNSS.
- White Rabbit, now part of IEEE 1588-2019 as the High Accuracy profile, reaches sub-nanosecond accuracy and is gaining ground in financial infrastructure.
What is PTP (IEEE 1588)?
PTP — the Precision Time Protocol defined in IEEE 1588 — synchronises clocks across a network to sub-microsecond accuracy. A reference clock exchanges timestamped messages with every device, measures the network delay between them and corrects each device’s clock. In trading, PTP is the standard way to keep servers, switches and capture appliances on the same time.
IEEE first published the standard in 2002. Version 2 (IEEE 1588-2008) improved accuracy and introduced profiles; IEEE 1588-2019 (sometimes called v2.1) added the High Accuracy profile and security features. The IEEE standard states that sub-microsecond accuracy is normal and that sub-nanosecond time transfer is possible in a properly designed network.
Why trading needs precise time
Trading firms need precise time for four reasons: regulators require accurate, UTC-traceable timestamps; latency can only be measured if clocks agree; order books and audit trails must be reconstructed in the right sequence; and best-execution analysis depends on knowing exactly when each event happened.
- Regulation: MiFID II RTS 25 in Europe and the Consolidated Audit Trail in the US set maximum divergence from UTC.
- Latency measurement: a firm cannot tell whether it lost a race by 2 or 20 microseconds without synchronised hardware clocks.
- Event sequencing: reconstructing a market event across venues requires timestamps that can be compared.
- Disputes and TCA: precise timestamps settle questions about fills, rejects and last-look hold times.
How PTP works
PTP uses a hierarchy of clocks. A grandmaster sends Sync messages with precise timestamps; each receiving clock replies with Delay Request messages. From the four timestamps, the device calculates both its offset from the master and the path delay, then steers its clock to match.
Sync, Follow-Up and Delay Request
- The master sends a Sync message and records the exact transmit time (t1).
- The slave records when Sync arrives (t2). In two-step mode, the master sends t1 in a Follow-Up message.
- The slave sends a Delay Request and records its transmit time (t3).
- The master records the arrival time (t4) and returns it in a Delay Response.
The slave computes the mean path delay as ((t2 − t1) + (t4 − t3)) / 2 and the offset from the master as (t2 − t1) − delay. The calculation assumes a symmetric path, which is why asymmetry is the main enemy of PTP accuracy.
Figure 1: The PTP delay request-response exchange
Grandmaster, boundary and transparent clocks
- Grandmaster: the reference clock, chosen by the Best Master Clock Algorithm and usually disciplined by GNSS.
- Boundary clock: a switch that synchronises to the upstream master and acts as master for downstream devices, stopping errors from accumulating.
- Transparent clock: a switch that measures how long each PTP packet spent inside it and adds that “residence time” to a correction field.
- Ordinary clock: an end device such as a server NIC.
PTP profiles
A PTP profile fixes the options for a specific industry: message rates, transport, clock types and accuracy targets. Trading networks commonly use the default or enterprise profiles; telecom, power and audio-video industries have their own. The High Accuracy profile in IEEE 1588-2019 standardises White Rabbit.
| Profile | Typical use | Notes |
|---|---|---|
| Default (delay request-response) | Enterprise and trading networks | UDP over IPv4/IPv6, ports 319/320 |
| Enterprise profile | Financial and enterprise networks | Mixed multicast/unicast |
| ITU-T G.8275.x (telecom) | Mobile and telecom networks | Full or partial on-path support |
| IEEE 802.1AS (gPTP) | Automotive, audio-video, TSN | Layer 2, peer-to-peer delay |
| High Accuracy (IEEE 1588-2019) | Science, finance, critical timing | White Rabbit, sub-nanosecond |
Hardware versus software timestamping
Software timestamps are taken when the operating system handles a packet and can be off by tens of microseconds. Hardware timestamps are taken by the network card or switch as the packet crosses the wire, cutting error to nanoseconds. Accurate PTP in trading always relies on hardware timestamping.
On Linux, the common open-source stack is linuxptp: ptp4l synchronises the NIC’s hardware clock to the network, and phc2sys synchronises the system clock to the NIC. Monitoring the reported offset and path delay over time is the simplest way to prove compliance.
PTP vs NTP vs GNSS
NTP typically achieves around a millisecond over general networks using software timestamps. PTP reaches sub-microsecond accuracy on a local network with hardware support. GNSS receivers such as GPS provide the absolute UTC reference that grandmasters use; PTP then distributes that time inside the data center.
| Method | Typical accuracy | Role in trading |
|---|---|---|
| NTP | ~1 millisecond | Office systems, non-critical servers |
| PTP with hardware timestamping | Sub-microsecond | Trading servers, switches, capture |
| White Rabbit | Sub-nanosecond | High-precision distribution |
| GNSS (GPS, Galileo) | Tens of nanoseconds to UTC | Grandmaster reference |
GNSS signals can be jammed or spoofed, so robust designs include holdover oscillators (oven-controlled crystal or rubidium) and, increasingly, terrestrial or fiber-delivered time services as backup.
Regulatory clock requirements: MiFID II RTS 25 and CAT
In Europe, RTS 25 requires firms using high-frequency trading to stay within 100 microseconds of UTC with 1-microsecond granularity, other algorithmic trading within 1 millisecond and voice trading within 1 second. In the US, CAT rules require industry members to stay within 50 milliseconds of NIST time and exchanges within 100 microseconds.
MiFID II RTS 25 — members and participants
| Type of trading activity | Max divergence from UTC | Timestamp granularity |
|---|---|---|
| High-frequency algorithmic trading | 100 microseconds | 1 microsecond or better |
| Voice trading systems | 1 second | 1 second or better |
| Request-for-quote with human response; negotiated trades | 1 second | 1 second or better |
| Other algorithmic trading | 1 millisecond | 1 millisecond or better |
Trading venues with gateway-to-gateway latency of 1 millisecond or less must stay within 100 microseconds with 1-microsecond granularity; slower venues within 1 millisecond.
United States. FINRA Rule 6820 requires CAT industry members to synchronise business clocks used for CAT reporting within 50 milliseconds of the NIST atomic clock, while exchanges and other CAT participants must meet a 100-microsecond tolerance. The tolerance includes drift and transmission delay — total error must stay inside the limit.
Both regimes also require UTC traceability: documented evidence linking a firm’s clocks to an official time source.
Figure 2: Maximum clock divergence allowed by regulation
White Rabbit: sub-nanosecond time
White Rabbit, developed at CERN, extends PTP with frequency syntonisation over the Ethernet physical layer, phase-based timestamps and automatic asymmetry compensation. It reaches sub-nanosecond accuracy and was standardised in IEEE 1588-2019 as the High Accuracy profile.
For trading firms, White Rabbit is attractive where microseconds are no longer enough: measuring FPGA tick-to-trade paths, comparing events across colocated sites or distributing time across a metro area. It requires compatible switches and NICs but interoperates with standard PTP devices.
Designing a PTP network for trading
A robust trading timing design uses redundant GNSS-disciplined grandmasters, boundary clocks in every switching layer, hardware timestamping on every critical NIC, continuous offset monitoring with alerts and documented UTC traceability for regulators.
A practical checklist:
- Deploy at least two grandmasters with independent GNSS antennas and holdover oscillators.
- Use PTP-aware switches (boundary or transparent clocks) on the timing path.
- Enable hardware timestamping on servers, capture appliances and FPGA cards.
- Monitor offset, path delay and grandmaster changes; alert well before regulatory limits.
- Keep records proving traceability and accuracy for audits.
Figure 3: A resilient PTP timing architecture
Frequently asked questions
What is PTP (IEEE 1588)?
PTP, the Precision Time Protocol defined in IEEE 1588, is a network protocol that synchronises clocks across devices to sub-microsecond accuracy. It measures the delay between a master clock and each device using timestamped message exchanges and corrects each clock accordingly.
What is the difference between PTP and NTP?
NTP typically synchronises clocks to around a millisecond over general networks using software timestamps. PTP uses hardware timestamping and network-aware clocks to reach sub-microsecond accuracy on a local network, which is why trading systems use PTP.
What clock accuracy does MiFID II require?
Under RTS 25, members using high-frequency algorithmic trading must keep business clocks within 100 microseconds of UTC with 1-microsecond timestamp granularity. Other algorithmic trading requires 1 millisecond; voice and similar activity requires 1 second. Venues with gateway-to-gateway latency of 1 millisecond or less must stay within 100 microseconds.
Does PTP need GPS?
PTP itself does not, but the grandmaster clock needs a traceable time source. Most trading firms discipline grandmasters with GNSS receivers such as GPS, backed by holdover oscillators or terrestrial time services in case satellite signals are lost or spoofed.
What is White Rabbit?
White Rabbit is an extension of PTP developed at CERN that adds frequency syntonisation over Ethernet and phase-based timestamping to reach sub-nanosecond accuracy. It was incorporated into IEEE 1588-2019 as the High Accuracy profile.
Sources and further reading
- IEEE 1588-2019 Standard for a Precision Clock Synchronization Protocol — IEEE Standards Association, 2020
- Commission Delegated Regulation (EU) 2017/574 (RTS 25) on business clock accuracy — European Union, 2017
- FINRA Rule 6820 — Clock Synchronization — FINRA
- The White Rabbit protocol and IEEE 1588 — CERN — white-rabbit.tech
Svetlana Berezhnova is a co-founder of Westernpips and has been a trader since 2007. She has been with the company from its very beginning and is an expert in high-frequency trading and latency-sensitive trading software.
This article is for educational purposes and describes market structure; it is not investment, legal or tax advice. Statistics are attributed to their original sources, which should be consulted for methodology and limitations.
