NTP vs PTP: Choosing the Right Time Synchronization for Your Network

Picture a symphony orchestra — except every musician is locked in a separate room, each reading from their own watch. If the watches disagree by a minute, the concert is a disaster. Computers have the same problem: every server has its own clock, and no two clocks tick at exactly the same speed. Left alone, a typical computer clock drifts by seconds per day.

The question is how far off you're allowed to be. For most of IT, "within a few milliseconds" is plenty. For a trading venue stamping orders under MiFID II — where regulators require timestamps accurate within 100 microseconds of UTC — or a 5G cell tower that must line up its radio bursts with its neighbors within about a microsecond, milliseconds are a joke. That split is why networks have two completely different time protocols: NTP and PTP.

Why time sync matters

Time is the one thing every device in a network is supposed to share. Here is what breaks when they don't:

• Log correlation. When an incident spans 40 devices, you reconstruct one timeline from all their logs. A firewall log stamped 3 seconds behind the server log makes cause and effect unreadable.
• Security forensics. Certificates expire, Kerberos tickets are rejected if they're stamped more than 5 minutes off, and audit trails are worthless if the clock was lying.
• HFT tick timestamps. Trading venues must prove the exact order of market events. Under MiFID II's RTS 25, high-frequency trading timestamps must be accurate within 100 microseconds of UTC with 1-microsecond granularity — a legal requirement, not an engineering preference.
• 5G radios. Neighboring cell towers transmitting on the same frequency must line up their transmit windows within about a microsecond, or they jam each other.
• Distributed databases. Ordering transactions across nodes in different data centers needs one shared clock story.

How NTP works: the copy-of-a-copy clock

NTP organizes time as a hierarchy of strata. Stratum 0 is the truth — an atomic clock or a GPS receiver. Stratum 1 servers sync directly to it. Your laptop usually sits at stratum 3 or 4: a copy of a copy of a copy. Each hop down adds a little error, like a photocopy of a photocopy.

A client polls its server over UDP port 123 and stamps four times: T1 when it sends the request, T2 when the server receives it, T3 when the server replies, T4 when the client gets the reply. Assuming the trip there took as long as the trip back, the client's offset from true time is ((T2−T1) + (T3−T4)) / 2. NTP polls slowly — every 64 seconds by default, stretching to 1,024 seconds when the clock looks stable — and smooths the results over many samples.

Typical accuracy: 1–50 milliseconds over the internet, and roughly 0.1–1 millisecond on a well-run LAN. NTP's blind spot: it assumes the path is symmetric. If the route there is slower than the route back, NTP bakes half the difference into your clock as a permanent error — and can never tell you.

How PTP works: timestamping at the wire

PTP (IEEE 1588) starts from a grandmaster clock — usually disciplined by GPS — and does a four-message dance. The grandmaster sends Sync (timestamp T1), optionally followed by Follow_Up carrying the precise hardware send time; the slave records when Sync arrived (T2), then replies with Delay_Req (T3); the grandmaster stamps its arrival (T4) and returns it in Delay_Resp. The slave computes its clock error as ((T2−T1) − (T4−T3)) / 2. The round trip cancels the travel time, so the slave learns its offset directly instead of guessing.

The whole trick is hardware timestamping. NTP stamps packets in software, where operating-system scheduling jitter adds tens of microseconds of noise. PTP stamps at the network port itself, taking the OS out of the measurement entirely. With that plus PTP-aware switches, accuracy lands at sub-microsecond — often tens of nanoseconds per hop.

Switches can join the timing chain two ways. A boundary clock terminates the timing at each hop and starts fresh — jitter never accumulates down a long chain. A transparent clock just measures how long each PTP packet sat inside it and adds that to the packet's correction field.

One companion worth knowing: SyncE. PTP tells you the time of day; SyncE gives you a rock-solid tick rate. Telecom networks often run both — frequency from SyncE, time-of-day from PTP.

Example: timing fabric in a colocation cage

Here is what PTP looks like in a real trading colocation setup — the kind of place where a microsecond is a budget line:

A PTP Sync message on the wire

PTP over Ethernet uses EtherType 0x88F7 and a multicast address every slave listens to. Here is a real-format Sync message — 58 bytes on the wire. Each color is one field — expand a field to see what every byte means:

01 1b 19 00 00 00  02 0f b5 11 22 33  88 f7 00 02
00 2c 00 00 00 00  00 00 00 00 00 00 00 00 00 00 00 00  02 0f b5 ff fe 11 22 33  00 01
00 00 02 0f b5 ff fe 11 22 33 00 01 01 f4 00 00
00 00 6a b1 3b 80  1d cd 65 00

■ Ethernet header  ■ type + version  ■ length  ■ flags + correction  ■ source port identity  ■ sequence + control  ■ origin timestamp

NTP vs PTP: the comparison

Decision guide: which one do you need?

NTP is enough when:

• You're on Active Directory — Kerberos tolerates clocks 5 minutes apart.
• You're correlating logs across an enterprise — millisecond accuracy keeps the timeline readable.
• You run web and API servers — certificate validity and request logs don't need microseconds.

You need PTP when:

• Regulators demand it — MiFID II's 100-microsecond rule for HFT timestamps.
• You're running 5G fronthaul — radios must align within about a microsecond.
• You measure tick-to-trade latency — timestamps from a sloppy clock make your latency numbers fiction. Before buying hardware, build your IEEE 1588 error budget from spec tables with the PTP timing budget calculator, and model a full multi-hop PTP network in the timing simulator.

Four real mistakes

1. Running PTP over the public internet. Internet jitter is measured in milliseconds; PTP's math needs nanoseconds. PTP assumes a controlled LAN — across the internet, use NTP and accept the milliseconds.
2. Asymmetric paths. PTP's offset formula assumes the trip there equals the trip back. If the fiber pair or routed path is slower one way, half the difference becomes a permanent, invisible clock error. Verify path symmetry before trusting PTP.
3. Virtual machines without PTP-aware plumbing. A guest's clock is emulated by the hypervisor. Without paravirtualized time or NIC passthrough, software-timestamping jitter swamps PTP's precision — the VM believes it's synced, but it isn't.
4. One grandmaster, no backup. The grandmaster is a single point of failure. PTP's Best Master Clock Algorithm only saves you if a second clock is standing by to be elected — deploy at least two.