Clock Synchronisation And PTP Timestamping

If two servers in the same data center measure the time an order took to reach the exchange, and their clocks are a millisecond apart from each other, the measured latency is meaningless — a genuine 50-microsecond round trip could get reported as anywhere from negative to over a millisecond depending purely on the clock drift, not the actual network. Ordinary computer clocks drift by milliseconds per day without correction, which is fine for scheduling a meeting but useless for a trading system where the entire point is measuring and comparing events down to microseconds across dozens of machines. Every clock in the stack has to agree, precisely, or the measurements built on top of them are fiction.

What PTP does differently from NTP

The internet's everyday time-sync standard, NTP (Network Time Protocol), gets clocks to agree within milliseconds — good enough for a laptop, useless for a trading floor. The Precision Time Protocol (PTP, IEEE 1588) achieves nanosecond-to-low-microsecond accuracy instead, mainly by moving the timestamping down into the network hardware itself rather than leaving it to software. A PTP-aware switch stamps the exact moment a synchronization message physically leaves or enters a port, eliminating the unpredictable delay software would otherwise add while an operating system gets around to processing the packet — that operating-system jitter is exactly what limits NTP's accuracy. A grandmaster clock, typically disciplined by GPS, is the reference every other clock in the network synchronizes against through a hierarchy of PTP-aware switches passing corrected time down the chain.

Regulators have made this concrete: MiFID II in Europe requires high-frequency trading firms to timestamp their systems to within 100 microseconds of UTC (and in some cases 1 microsecond), specifically because without a synchronized clock, reconstructing "what happened first" across a market event — which order arrived before which cancellation — is not just imprecise, it's impossible to establish at all.

Worked example: comparing two clocks

A firm's order-entry server logs an order sent at local timestamp 10:00:00.000412 (412 microseconds past the second). The exchange's matching engine, using its own PTP-synchronized clock, logs the order received at 10:00:00.000397 — apparently 15 microseconds before it was sent, which is physically impossible. The explanation isn't time travel; it's clock drift. If a later PTP audit shows the firm's server clock was running 20 microseconds fast relative to the grandmaster, the corrected send time is 10:00:00.000392, and the trip actually took a sensible 5 microseconds. Without knowing the clocks were misaligned by exactly that 20 microseconds, the firm would have no way to tell whether its 15-microsecond "negative latency" was a clock problem or a genuine anomaly worth investigating.

What this means in practice

Any latency measurement, event-ordering claim, or regulatory timestamp report is only as trustworthy as the clock synchronization underneath it — a firm can build a beautifully instrumented system and still draw wrong conclusions if the clocks feeding those instruments silently drift apart. Deploying and monitoring PTP infrastructure (grandmaster clocks, PTP-aware switches, periodic drift audits) is table-stakes engineering for any firm doing serious latency-sensitive trading or subject to MiFID II-style timestamp accuracy requirements.