Why Time Accuracy Matters

In trading, time is money-literally. Regulatory frameworks like MiFID II require timestamps accurate to 100 microseconds. More importantly, if your clock is 1ms off, you might:

• Miss the true sequence of events during disputes
• Have compliance logs rejected by regulators
• Lose arbitrage opportunities to competitors with better clocks

This lesson explains why NTP can’t solve this and how PTP does.

---

What You’ll Learn

By the end of this lesson, you’ll understand:

1. Why NTP fails for HFT - Software timestamps are inherently jittery
2. How PTP works - Master-slave synchronization with hardware support
3. Hardware timestamping - Bypassing the kernel for nanosecond accuracy
4. Compliance requirements - MiFID II, CAT, and audit trail needs

---

The Foundation: Why NTP Isn’t Enough

NTP (Network Time Protocol) synchronizes clocks over the internet. It’s fine for most applications-but fundamentally broken for HFT.

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

That's a 10,000x to 1,000,000x difference.

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 “Aha!” Moment

Here’s what most engineers don’t realize:

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.

---

Let’s See It In Action: Checking PTP Status

First, verify if your NIC supports hardware timestamping:

# 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)

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

Now check PTP sync status:

# 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

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

---

PTP Architecture

PTP uses a master-slave hierarchy:

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 alone can’t sync your trading servers.

Myth: “Software PTP (ptp4l) is good enough.”
Reality: Without hardware timestamping, software PTP is only marginally better than NTP. The magic is in SOF_TIMESTAMPING_TX_HARDWARE.

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

---

Hardware Timestamping Deep Dive

Here’s how to configure hardware timestamping on Linux:

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

[eth0]
egressLatency 0
ingressLatency 0

Start PTP:

# 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!)

Then sync your system clock to PTP:

# 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)

---

Regulatory Requirements

Regulation	Accuracy Required	Notes
MiFID II	±100µs	For HFT/market making
CAT (US)	±50ms	Less stringent
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

---

Practice Exercises

Exercise 1: Check Your Hardware

# Verify PTP support
ethtool -T eth0

# What capabilities do you see?

Exercise 2: Monitor PTP Offset

# Watch offset in real-time
watch -n1 'pmc -u -b 0 "GET CURRENT_DATA_SET" | grep offset'

Exercise 3: Compare NTP vs PTP

# 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 - 1,000,000x difference
2. Hardware timestamping is essential - Software PTP is nearly useless
3. The NIC has its own clock - PTP syncs hardware clocks, not software
4. PTP-aware switches matter - Standard switches add jitter

---

What’s Next?

🎯 Continue learning: CPU Isolation for HFT

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

Now you know why trading firms spend $100K+ on time synchronization infrastructure. ⏱️