Why Time Accuracy Matters

Regulatory frameworks like MiFID II require timestamps accurate to 100 microseconds for HFT firms. More practically: if your clock is 1ms off, you might miss the true sequence of events during a dispute, have compliance logs rejected, or lose arbitrage opportunities to competitors with better clocks.

This lesson explains why NTP falls short and how PTP solves it.

---

Why NTP Isn’t Enough

NTP (Network Time Protocol) synchronizes clocks over the internet. It’s fine for most applications — but not for trading.

NTP Accuracy: ± 1-50 milliseconds
PTP Accuracy: ± 10-100 nanoseconds
```python

### Why NTP Fails

1. **Software timestamps**: NTP uses kernel interrupts. By the time your application sees the timestamp, 10-100µs have passed.
2. **Asymmetric paths**: NTP assumes equal latency both ways. In reality, network paths are often asymmetric.
3. **No hardware support**: NTP runs entirely in software — it can't access the NIC's hardware clock.

---

## The Key Insight

**Your NIC has a hardware clock separate from your CPU clock.** PTP synchronizes these hardware clocks directly, bypassing the kernel entirely. That's why PTP achieves nanoseconds while NTP struggles with milliseconds.

When a packet arrives, the NIC's hardware clock stamps it *before* the kernel even knows. That's hardware timestamping.

---

## Checking PTP Status

First, verify if your NIC supports hardware timestamping:

```bash
# Check hardware timestamp capabilities
ethtool -T eth0 | grep -A10 "Capabilities"

# Expected output for PTP-capable NIC:
# Capabilities:
#     hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
#     hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
#     hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
```text

If you see `hardware-transmit` and `hardware-receive`, your NIC supports PTP.

Now check PTP sync status:

```bash
# Check ptp4l status
systemctl status ptp4l

# See current offset from master
pmc -u -b 0 'GET CURRENT_DATA_SET'

# Output:
#   offsetFromMaster  -47ns  ← This is your error
#   meanPathDelay     1.2µs
```sql

The `offsetFromMaster` tells you how far your clock is from the grandmaster. Under 100ns is excellent.

---

## PTP Architecture

PTP uses a master-slave hierarchy:

```text
Grandmaster Clock → Boundary Clock → Your NIC → Application
```bash

### Key Messages

| Message | Direction | Purpose |
|---------|-----------|---------|
| **Sync** | Master → Slave | "Here's my time" |
| **Follow_Up** | Master → Slave | "That Sync was sent at time T1" |
| **Delay_Req** | Slave → Master | "What time did you receive this?" |
| **Delay_Resp** | Master → Slave | "I received it at T4" |

With four timestamps (T1, T2, T3, T4), the slave calculates the path delay and adjusts its clock.

---

## Common Misconceptions

**Myth:** "GPS is all you need for time sync."
**Reality:** GPS gives you ~50ns accuracy at the grandmaster, but you still need PTP to distribute that time across your network. GPS synchronizes the grandmaster clock; PTP distributes it to all nodes.

**Myth:** "Software PTP (ptp4l) is good enough."
**Reality:** Without hardware timestamping, software PTP is only marginally better than NTP. The accuracy improvement comes from hardware timestamps, not the protocol itself.

**Myth:** "Any switch works for PTP."
**Reality:** Standard switches add variable delay per hop (1-10µs). You need PTP-aware switches (boundary clocks) or transparent clocks to maintain accuracy across multiple hops.

---

## Hardware Timestamping Deep Dive

Here's how to configure hardware timestamping on Linux:

```bash
# /etc/ptp4l.conf
[global]
domainNumber 0
priority1 128
priority2 128
slaveOnly 1
clock_servo linreg
delay_mechanism E2E

[eth0]
egressLatency 0
ingressLatency 0
```text

Start PTP:

```bash
# Start ptp4l with hardware timestamping
ptp4l -i eth0 -m -H

# Flags:
# -i eth0  : Use this interface
# -m       : Print to stdout
# -H       : Use hardware timestamping (critical!)
```text

Then sync your system clock to PTP:

```bash
# Sync kernel clock to PTP hardware clock
phc2sys -s eth0 -c CLOCK_REALTIME -O 0 -m

# -s eth0  : Source is the NIC's PHC (PTP Hardware Clock)
# -c CLOCK_REALTIME : Destination is system clock
# -O 0     : Zero offset (no TAI-UTC conversion)
```bash

---

## Regulatory Requirements

| Regulation | Accuracy Required | Notes |
|------------|------------------|-------|
| **MiFID II** | ±100µs | For HFT/market making (100ns for some categories) |
| **CAT (US)** | ±50ms | Less stringent for broker-dealers |
| **Exchange Rules** | Varies | Often stricter than regulation |

MiFID II specifically requires:
- Timestamps on all order events
- Logs retained for 5 years
- Accuracy traceable to UTC

Note: MiFID II has different requirements depending on firm category. HFT firms face the strictest requirements (1µs or 100µs depending on activity). Check the RTS 25 regulation for specifics.

---

## Practice Exercises

### Exercise 1: Check Your Hardware
```bash
# Verify PTP support
ethtool -T eth0

# What capabilities do you see?
```text

## Exercise 2: Monitor PTP Offset
```bash
# Watch offset in real-time
watch -n1 'pmc -u -b 0 "GET CURRENT_DATA_SET" | grep offset'
```text

## Exercise 3: Compare NTP vs PTP
```bash
# Check NTP offset
chronyc tracking | grep "System time"

# Compare to PTP offset
pmc -u -b 0 'GET CURRENT_DATA_SET' | grep offset

---

Key Takeaways

1. NTP ≈ milliseconds, PTP ≈ nanoseconds - The difference is hardware timestamping
2. Hardware timestamping is essential - Software PTP without it gives marginal improvement
3. The NIC has its own clock - PTP syncs hardware clocks, not just software
4. PTP-aware switches matter - Standard switches add jitter at each hop

---

What’s Next?

CPU Isolation for HFT

PTP or Die: Hardware Timestamping for Regulatory-Grade Time Sync