IEEE 1588 PTP for sub-microsecond time sync: why NTP falls short, clock roles (grandmaster/OC/boundary/transparent), BMCA election, the Sync/Follow_Up/Delay_Req/Delay_Resp exchange & offset/path-delay math, one-step vs two-step, correction field, asymmetry & holdover, SyncE, and the MiFID II trading angle.
PTP (IEEE 1588) synchronizes clocks across a network to sub-microsecond — even nanosecond accuracy, where NTP manages only milliseconds. For a trading-focused shop it's not optional: MiFID II mandates timestamps traceable to UTC within tight bounds, and accurate ordering of events is impossible without a common, precise clock. This is the theory to explain PTP end to end.
The two ideas that make PTP work where NTP can't: hardware timestamping (stamp the packet at the PHY, not in software) and on-path support (switches measure and subtract their own delay). Together they remove the OS jitter and queuing that wreck NTP.
| Role | What it does |
|---|---|
| Grandmaster (GM) | The time reference for the domain — almost always disciplined by GNSS/GPS. Everyone syncs to it. |
| Ordinary Clock (OC) | A single-port endpoint: either master or (usually) slave. |
| Boundary Clock (BC) | Recovers time as a slave on one port and regenerates it as master on others — terminates PTP per segment. Scales PTP and stops error accumulating. |
| Transparent Clock (TC) | Doesn't recover time; it measures its own residence time and adds it to the packet's correction field so the slave can subtract switch delay. End-to-end or peer-to-peer. |
On-path support is the point: a plain (non-PTP) switch adds variable queuing delay that the slave can't see — the accuracy killer. BCs and TCs make each hop's delay known.
The Best Master Clock Algorithm auto-selects the GM (and fails over) by comparing, in order: priority1 → clock class → accuracy → variance → priority2 → clock identity (tie-break). Announce messages advertise these; the best clock wins and everyone else becomes a slave. No manual master config, automatic recovery if the GM or its GNSS is lost.
A slave learns its offset from the master and the mean path delay from four timestamps:
master slave
| Sync (t1) ----→ | t2 t1 = egress time (master)
| Follow_Up (t1, two-step) | t2 = ingress time (slave)
| ←---------- Delay_Req (t3) | t3 t3 = slave sends request
| Delay_Resp (t4) ---------→ | t4 = master receives it
mean path delay = [(t2 - t1) + (t4 - t3)] / 2
offset = (t2 - t1) - meanPathDelay (assumes a symmetric path)t1 into the Sync as it leaves
(hardware); two-step sends t1 afterwards in a Follow_Up (simpler hardware, one extra
message).Pdelay measures each link's delay to the neighbor — pairs with
P2P transparent clocks).MiFID II RTS 25 requires business clocks to be traceable to UTC with bounded divergence (on the order of 100 µs for high-frequency activity) and fine timestamp granularity (down to 1 µs / ns). NTP can't meet that at scale, so the standard build is a GNSS-disciplined grandmaster → boundary/transparent-clock network → PTP hardware-timestamping NICs, with PPS/ToD distribution and holdover for GNSS outages. Pairs with Low-Latency & Trading.
linuxptp: ptp4l for PTP, phc2sys to sync the
system clock to the NIC's PHC).