# Clock Synchronization and PTP

> Accurate clocks are vital for timestamps, latency measurement and regulation. Learn how NTP and PTP work, MiFID II and CAT clock rules and how to check your clocks.

Source: https://learn.tradelabsai.com/infrastructure/clock-synchronization-and-ptp/  
Track: Trading Infrastructure · Level: Advanced · Updated: 2026-10-03  
Publisher: TradeLabs AI (https://tradelabsai.com). Education, not financial advice.  
Cite as: TradeLabs Learn, "Clock Synchronization and PTP", https://learn.tradelabsai.com/infrastructure/clock-synchronization-and-ptp/

Every timestamp a trading system records is only as good as the clock that produced it. Computer clocks drift, gaining or losing time every day. Without synchronisation, two servers can disagree by many milliseconds, making events appear in the wrong order, latency measurements meaningless and audit records unreliable. Regulators require firms to keep clocks within set limits of official time. The two main tools are NTP for everyday accuracy and PTP for precision measured in microseconds or better.

## Why clock accuracy matters

| Use | Problem with a bad clock |
|---|---|
| Ordering events across servers | Fills appear before the orders that caused them |
| Latency measurement | Negative or wildly wrong latencies. See [Exchange vs Receive Timestamps and Latency Measurement](https://learn.tradelabsai.com/programming/latency-measurement/) |
| Audit trails | Records fail regulatory standards. See [Logging, Audit Trails and Incident Response](https://learn.tradelabsai.com/algo-trading/audit-trails/) |
| Signed API requests | Brokers and exchanges reject requests with timestamps too far off |
| Scheduled actions | Jobs run at the wrong moment |

## NTP versus PTP

| | NTP (Network Time Protocol) | PTP (Precision Time Protocol, IEEE 1588) |
|---|---|---|
| Typical accuracy | Around a millisecond on a good network; worse over the internet | Sub microsecond with suitable hardware |
| Hardware needs | None special | Network cards and switches with hardware timestamping |
| Time source | Public or private NTP servers | Grandmaster clock, often GPS disciplined |
| Typical users | Most servers, retail systems | Exchanges, high frequency firms, regulated firms with strict requirements |

## Regulatory requirements

| Regulation | Requirement (summary) |
|---|---|
| EU MiFID II (RTS 25) | Clocks synchronised to UTC; for high frequency algorithmic trading, maximum divergence of 100 microseconds with 1 microsecond timestamp granularity; looser limits for other activity |
| US Consolidated Audit Trail | Industry member clocks synchronised within 50 milliseconds of NIST time for most systems, with tighter rules for exchanges |

Firms must also document their synchronisation and be able to show traceability to UTC.

**Example: A clock skew mystery**
A trader measures order round trip times by comparing the send time on the trading server with the exchange's acknowledgement timestamp. Some round trips come out negative, which is impossible. The trading server's clock, synced only to a distant public NTP server, is running 3 milliseconds ahead. Switching to a nearby, reliable NTP source brings the offset under 0.2 milliseconds and the negative values disappear. Better still, the trader measures round trips using only the local monotonic clock, from send to acknowledgement receipt, and uses the exchange timestamps only for the one way breakdown. See [Timestamps, Time Zones and Daylight Saving](https://learn.tradelabsai.com/programming/timestamps-and-time-zones/).

## How PTP achieves precision

1. **A grandmaster clock,** usually locked to GPS or another reference, provides the time.
2. **Messages are timestamped in hardware** by network cards as they leave and arrive, removing software delays.
3. **Switches correct for their own delays** (boundary or transparent clocks).
4. **Clients calculate the offset and network delay** from exchanged messages and adjust.

## Checking your clocks on Linux

| Command | Shows |
|---|---|
| `timedatectl status` | Whether synchronisation is active |
| `chronyc tracking` | Current offset and stability with chrony |
| `chronyc sources -v` | Which time servers are used |
| `ptp4l` and `phc2sys` logs | PTP synchronisation state |

Chrony is a common modern NTP implementation and generally keeps time more accurately than older tools. Monitor the offset as a metric and alert if it exceeds your tolerance. See [Monitoring and Logging Systems](https://learn.tradelabsai.com/infrastructure/monitoring-and-logging-systems/).

## Best practices

- **Use nearby, reliable time sources,** several of them.
- **Never let clocks jump during trading:** slew (gradually adjust) instead of stepping.
- **Monitor offsets** continuously and record them.
- **Use monotonic clocks for durations** and synchronised wall clocks for timestamps.
- **Store timestamps in UTC.** See [Timestamps, Time Zones and Daylight Saving](https://learn.tradelabsai.com/programming/timestamps-and-time-zones/).

## Frequently asked questions

### What is PTP in trading?

The Precision Time Protocol, which synchronises clocks across a network to sub microsecond accuracy using hardware timestamping, used by exchanges and latency sensitive firms.

### Is NTP accurate enough for trading?

For most retail and many institutional uses, yes; strict regulatory requirements for high frequency trading typically call for PTP.

### What are the MiFID II clock synchronisation rules?

Firms must synchronise to UTC within set limits, with the strictest being 100 microseconds divergence and 1 microsecond granularity for high frequency algorithmic trading.

You have finished the Infrastructure track. Continue with machine learning in [Machine Learning in Trading](https://learn.tradelabsai.com/machine-learning/machine-learning-in-trading/).

## Continue learning

- Previous lesson: [Binary Protocols](https://learn.tradelabsai.com/infrastructure/binary-protocols/)
- Related: [Binary Protocols](https://learn.tradelabsai.com/infrastructure/binary-protocols/): Why exchanges use compact binary protocols for market data and orders. Learn how ITCH, OUCH and SBE work, how they compare with JSON and FIX, and decoding basics.
- Related: [Timestamps, Time Zones and Daylight Saving](https://learn.tradelabsai.com/programming/timestamps-and-time-zones/): Time zone and timestamp errors silently break backtests. Learn UTC storage, daylight saving traps, exchange sessions, event versus receive time and bar labels.
- Related: [Exchange vs Receive Timestamps and Latency Measurement](https://learn.tradelabsai.com/programming/latency-measurement/): How to measure latency in a trading system: where to timestamp, tick to trade and order round trip, percentiles instead of averages and how to find bottlenecks.
- Related: [Logging, Audit Trails and Incident Response](https://learn.tradelabsai.com/algo-trading/audit-trails/): An audit trail records every signal, order, change and fill so trading can be reconstructed later. Learn what to log, the regulatory rules and how it helps traders.
- Related: [Linux for Traders](https://learn.tradelabsai.com/infrastructure/linux-for-traders/): The Linux skills traders need to run bots on servers: the command line, files, processes, services with systemd, logs, scheduling, SSH security and updates.
- Related: [Monitoring and Logging Systems](https://learn.tradelabsai.com/infrastructure/monitoring-and-logging-systems/): The tools behind trading observability: structured logs, metrics, dashboards, tracing and alerting with Prometheus, Grafana and log stacks, and how to set them up.