PTP vs NTP: When Microseconds Actually Matter

Most networks need to agree on what time it is to within a second or so, and NTP has done that job well for forty years. Then there are the networks where a second is an eternity: a trading floor where transaction ordering is legally auditable, a 5G fronthaul link where radio units must be phase-aligned, a substation where protection relays trip on microsecond timing, a broadcast plant where audio and video must stay locked.

For those, NTP is not merely imprecise. It is structurally incapable of the job. PTP (Precision Time Protocol, IEEE 1588) exists because of a specific insight about why NTP is limited, and understanding that insight is more useful than memorising either protocol. This article extends the IP Services cluster guide.

A Platform Note, Up Front

Every other article in this cluster shows real captures from the lab. This one shows real NTP output, because the lab genuinely runs NTP, and it shows no PTP output at all, because the platforms available here do not support it:

R1(config)# ptp mode boundary
            ^
% Invalid input detected at '^' marker.

IOL-XE has no PTP. Neither does the Catalyst 8000v build used elsewhere in this lab. This is not a limitation of virtualization in the abstract; it is a consequence of what PTP fundamentally requires, and that turns out to be the most instructive fact in the whole article. We will come back to it.

PTP genuinely runs on Catalyst 9000 series switches, Cisco IE industrial switches, ASR 900 series, and NCS platforms. If you need to lab it, that is the hardware. What follows is the mechanism, the real NTP numbers for contrast, and honest guidance. No fabricated PTP output appears anywhere on this site.

The Core Problem: Asymmetry

Both protocols solve the same puzzle. A client wants to know the server's time, but the answer takes time to arrive, so by the time it lands it is already stale. Both correct for this the same way: measure the round trip, assume the delay was symmetric, and subtract half of it.

offset = ((T2 - T1) + (T3 - T4)) / 2
delay  = ((T4 - T1) - (T3 - T2)) / 2

  T1 = client sent request        T2 = server received it
  T3 = server sent reply          T4 = client received it

That halving is the whole ballgame. It is exactly correct if the path took the same time in both directions, and it is wrong by half the asymmetry if it did not. A path that is 10ms out and 20ms back does not produce a 5ms error; it produces an error you cannot even detect, because the arithmetic has no way to notice.

Everything that makes a network fast and efficient makes this worse. Queueing delay varies with load. Different forward and return paths have different lengths. A switch under congestion holds your timing packet in a buffer for an unpredictable interval. Every one of these injects asymmetry, and every microsecond of asymmetry becomes half a microsecond of undetectable clock error.

You can watch it happen

Here is NTP in the lab, with the client synchronised to a master one hop away. The link between them is deliberately degraded (120ms latency, 40ms jitter, 8 percent loss) using link conditioning:

R2#show ntp status
Clock is unsynchronized, stratum 4, reference is 1.1.1.1
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**10
reference time is EDFD6558.B8D4FFF0 (00:59:04.722 UTC Sun Jul 12 2026)
clock offset is -52.5000 msec, root delay is 105.00 msec
root dispersion is 73.22 msec, peer dispersion is 3.01 msec
loopfilter state is 'FREQ' (Drift being measured)
system poll interval is 64, last update was 180 sec ago.

R2#show ntp associations

  address         ref clock       st   when   poll reach  delay  offset   disp
*~1.1.1.1         127.127.1.1      3    180     64    36 105.00 -52.500  3.019
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

Read the numbers. Root delay 105ms. Clock offset -52.5ms. Dispersion 3ms. The offset is almost exactly half the delay, which is the algorithm doing precisely what it was designed to do. And it is guessing: NTP has no way to know whether that 105ms was split evenly. The dispersion figure of 3ms is NTP's own honest estimate of its uncertainty.

Note also Clock is unsynchronized and loopfilter state is 'FREQ': even while it has selected a peer (the * in the associations output), the router is refusing to declare itself synchronised because the path quality is too poor to trust. NTP knows when it is being lied to by the network, and says so.

That output is the case for PTP, made by NTP itself.

What PTP Does Differently

PTP does not use a smarter formula. It uses the same one. What it changes is where the timestamps are taken and what the network in between does.

Hardware timestamping

The timestamp is taken by the PHY, as the bits hit the wire. NTP timestamps in software, so the OS scheduler, interrupt latency, and driver queues are all inside the measurement.

Transparent clocks

Every switch in the path measures how long it held the packet and writes that into a correction field. Queueing delay stops being invisible and becomes a known quantity.

Boundary clocks

A switch terminates PTP on one side and re-originates it on the other, so error does not accumulate across a long path. Each hop is a fresh, short measurement.

BMCA

The Best Master Clock Algorithm elects a grandmaster automatically from clock quality attributes. No manual stratum config.

The transparent clock is the conceptual leap. NTP treats the network as an opaque box that adds an unknown delay. PTP makes the network participate: each switch confesses exactly how long it delayed the packet, so the receiver can subtract it. Asymmetry caused by queueing simply stops existing as a source of error.

And that is precisely why the lab cannot run it. PTP requires the forwarding hardware to timestamp packets in the PHY and rewrite a correction field at line rate. A virtual router has no PHY. There is no silicon to do it. This is not Cisco declining to implement a feature in a virtual image; it is a feature that has nowhere to live without hardware. The command being rejected is the honest answer.

The Numbers That Matter

NTP over the internet10 to 100 milliseconds. Fine for logs, certificates, Kerberos.

NTP on a good LANUnder 1 millisecond, typically a few hundred microseconds.

PTP, software timestampingTens of microseconds. Better than NTP, but the OS is still in the loop.

PTP, hardware timestamping + transparent clocksSub-microsecond, often tens of nanoseconds. This is the whole point.

Roughly four orders of magnitude between well-run NTP and well-run PTP. But note the third row: PTP without hardware support is barely better than NTP. Deploying PTP on switches that lack transparent-clock silicon buys you complexity and very little accuracy. This is the most common way PTP projects disappoint.

Which Do You Need?

Be honest about the requirement, because PTP is a genuine infrastructure commitment.

NTP is correct for: log correlation, certificate validity, Kerberos and AD authentication (which tolerates about 5 minutes), scheduled jobs, and roughly 95 percent of enterprise networks. If someone cannot articulate a sub-millisecond requirement, they need NTP.

PTP is required for:

Financial trading. MiFID II in Europe mandates 100-microsecond traceability to UTC for high-frequency venues. That is not achievable with NTP.
Mobile fronthaul. 5G TDD requires radio units phase-aligned to about 1.5 microseconds, or adjacent cells interfere with each other.
Power utilities. IEC 61850 substations run protection relays and synchrophasors on microsecond timing.
Broadcast. SMPTE 2110 replaced physical genlock cabling with PTP over the IP network. Lose PTP and the plant loses sync.
Industrial automation. Motion control across a factory floor, where axes must move in lockstep.

What all of these share: the timing is not for humans reading logs, it is a functional input to the system. If time is wrong, the thing does not work, as opposed to being mildly annoying to debug.

They Run Together

This is not an either/or decision. A trading floor runs PTP for the timestamping infrastructure and NTP for the wiki, the jump hosts, and the printers. A 5G RAN runs PTP to the radios and NTP on the management network.

PTP is expensive in the ways that matter: every switch in the timing path must support it, you need a grandmaster with a GNSS receiver (and therefore a roof antenna, and therefore a conversation with the building owner), and you need to think about GNSS holdover and spoofing. Nobody deploys it for the fun of it.

The pragmatic architecture: NTP everywhere as the baseline, PTP as a dedicated overlay on the specific paths that need it, with the PTP grandmaster itself disciplined by GNSS and NTP as its fallback.

Doing NTP Properly, Since That Is What You Will Actually Run

Given that NTP is what most networks need, it is worth doing well:

Use at least four sources. NTP's selection algorithm needs a quorum to detect a falseticker. Two sources is the worst possible number: when they disagree, the client cannot tell which one is lying.
Authenticate. ntp authenticate plus ntp trusted-key. An unauthenticated NTP client will believe anyone, and moving a device's clock is a real attack (it can expire or un-expire certificates, and break log correlation during an incident).
Restrict access. ntp access-group. An open NTP server is an amplification vector for DDoS.
Hierarchy, not a mesh. A couple of stratum-2 routers peering upstream, everything else pointing at them. The ntp master command on a router that has no real reference is a lie the rest of your network will believe.
Monitor the offset, not just reachability. A device that says it is synchronised at 200ms of offset is a device you want to know about.

FAQ

Can I run PTP in a virtual lab?

Not meaningfully. PTP's accuracy depends on PHY-level hardware timestamping and transparent-clock silicon, neither of which a virtual router has. IOL-XE rejects the config outright. You can run software PTP (linuxptp) between VMs to see the protocol exchange, but the accuracy will be NTP-grade and the exercise is about protocol mechanics, not timing.

Is PTP more accurate because it uses a better algorithm?

No. It uses essentially the same offset/delay maths. It is more accurate because it timestamps in hardware and because the switches in between report their own queueing delay instead of hiding it.

Does PTP need every switch in the path to support it?

For sub-microsecond accuracy, yes. A single non-PTP-aware switch in the path reintroduces exactly the unmeasured queueing delay that PTP exists to eliminate. This is why PTP deployments are infrastructure projects, not config changes.

What is a grandmaster?

The clock at the top of the PTP hierarchy, elected by the BMCA, usually disciplined by GNSS. Roughly the equivalent of a stratum-1 NTP server, but elected dynamically rather than configured.

Why does my NTP client say "unsynchronized" when it has a peer?

Because it does not trust the path yet. As the lab output shows, a peer can be selected (*) while the router still refuses to declare sync, because dispersion and delay are too high or the drift is still being measured (loopfilter state is 'FREQ'). Give it time, or fix the path.

Key Takeaways

Both protocols use the same offset maths and both assume the path is symmetric. Asymmetry is the entire source of error.
PTP is not more accurate because of better arithmetic. It is more accurate because it timestamps in the PHY and because transparent clocks report their own queueing delay instead of hiding it.
Because PTP needs timestamping silicon, it cannot run on virtual platforms. IOL-XE rejects ptp mode outright. That rejection is the concept, demonstrated.
Real NTP under a bad path, from the lab: root delay 105ms, offset -52.5ms, and the router honestly reporting Clock is unsynchronized.
PTP without hardware support is barely better than NTP. Half-deployed PTP is the classic disappointment.
NTP is right for ~95% of networks. PTP is required where time is a functional input: trading, 5G fronthaul, IEC 61850 substations, SMPTE 2110 broadcast, motion control.
Run NTP properly: four or more sources, authenticated, access-listed, hierarchical.

Next: the IP Services cluster guide.

PTP vs NTP: When Microseconds Matter