When NTP Is Fine for SCADA and When You Actually Need PTP

Someone asks for PTP because a vendor's substation spec sheet listed it, and three weeks later there's a grandmaster clock, a pile of boundary-clock switches, and a change order — all to timestamp tags that update every two seconds off a poll. That's the failure I see most: PTP bought to solve a problem the site never had. The opposite failure is quieter and worse — NTP trusted to align a sequence-of-events report across two substations to 1 ms, which it cannot do, and nobody notices until the post-fault analysis puts a downstream breaker tripping before the fault that caused it.

So the real question isn't "PTP or NTP." It's: how good does time have to be for what you're timestamping, and where does the timestamp actually get stamped? Answer those two and the protocol choice falls out.

What each one actually delivers

NTP (or SNTP, the stripped-down client most PLCs and RTUs ship) over a normal Ethernet LAN gets you into the low single-digit milliseconds against a decent stratum-1 source. Over a busy or hop-heavy network, or with a cheap SNTP client that does no filtering, you drift out to 10–50 ms and it wanders with load. That's the number to hold in your head: NTP is a "few to a few tens of milliseconds" technology. It's ordinary software timestamping, so switch queuing delay and OS scheduling jitter go straight into your offset.

PTP — IEEE 1588 — is a different mechanism, not just a faster NTP. The accuracy comes from hardware timestamping at the MAC layer and from network elements that measure and subtract their own transit delay. With PTP-aware switches in the path you land in the sub-microsecond to low-microsecond range. Without them, PTP degrades toward NTP-class numbers, which is exactly why people are disappointed when they drop a grandmaster onto plain unmanaged switches and see 2 ms — they paid for PTP and got NTP because the path wasn't PTP-aware.

The gap between them is three orders of magnitude, and most SCADA data doesn't care about any of it.

Match the clock to the timestamp

Walk your tags by how the timestamp is generated, because that's what decides whether accuracy matters:

• Polled analog and status, timestamped by the SCADA server on receipt. Your poll cycle is 1–5 seconds and the timestamp already carries hundreds of milliseconds of transport and scan latency. Synchronizing the server's clock to 1 µs is polishing a number that's fuzzy by design. NTP is not just adequate here, it's the correct engineering choice — cheaper, simpler, one less thing to commission.
• Report-by-exception / change-of-state with a device timestamp (DNP3 events, OPC UA source timestamps, MQTT payloads carrying their own time). Now the timestamp is stamped at the RTU/PLC when the event happened, and cross-device ordering starts to matter. NTP at a few ms is usually still fine — until you need to merge event streams from multiple devices and reason about their order.
• Sequence-of-events for protection and fault analysis. This is the one that needs real accuracy. IEEE C37.232 and utility practice call for 1 ms SOE resolution, and to trust the ordering of two events stamped by two different IEDs, the clocks stamping them must agree to well inside that 1 ms. NTP's few-milliseconds error is the same size as the thing you're trying to measure. This is where PTP earns its keep.
• IEC 61850-9-2 Sampled Values. Merging units publishing sampled analog values need sub-microsecond alignment so a protection relay can combine currents and voltages from different sources into one phasor. There's no NTP conversation to have here — the process bus assumes PTP.

Notice the pattern: accuracy requirements track who stamps the time and whether you compare stamps across devices, not the nominal importance of the signal. A critical breaker status that's polled and server-stamped needs less clock accuracy than a routine SOE record stamped in the field.

The PTP profile is not optional detail

If you do need PTP, "we're running 1588" is not a spec. IEEE 1588 has profiles, and mixing them gives you a grandmaster and slaves that will not lock. For power systems the relevant ones are the Power Profile, IEEE C37.238, and its IEC counterpart IEC 61850-9-3, which pin down the transport (Layer 2 multicast, peer-to-peer delay mechanism), the message rates, and a defined accuracy budget (C37.238 targets 1 µs across up to a set number of hops). General-industrial gear often ships the default or a telecom profile instead. A C37.238 grandmaster and an IEC 61850-9-3 device are close enough to interoperate; a default-profile switch in between that runs end-to-end delay instead of peer-to-peer will quietly wreck your delay correction. Check the profile on every device in the path before you buy, not after.

And the path is the whole game. PTP accuracy depends on every switch between grandmaster and slave either being a boundary clock (terminates PTP and regenerates it, re-timing on its own oscillator) or a transparent clock (measures how long the frame sat inside and writes that residence time into the correction field). One ordinary store-and-forward switch that does neither, sitting in the path, adds its queuing delay to your offset with no way to subtract it — and under load that delay is variable, so your error isn't even a constant you can calibrate out. A single non-PTP hop can turn a 1 µs system into a 100 µs one whenever traffic spikes.

Grandmaster, holdover, and the failure you don't see coming

The grandmaster clock disciplines to GNSS — GPS, usually — and that antenna on the roof is a single point of failure people forget until a lightning strike or a chewed cable takes it out. What happens next depends on the grandmaster's holdover: with GNSS lost, it free-runs on its internal oscillator, and a cheap TCXO drifts far faster than an OCXO or rubidium. The clock keeps handing out time and keeps claiming to be healthy; it just slowly walks away from truth. For SOE that only bites during a fault — which is exactly when GNSS might also be compromised.

Two things save you here. First, deploy redundant grandmasters and let the Best Master Clock Algorithm (BMCA) fail over — that's what BMCA is for, and it's worth testing that the failover actually happens by pulling the primary during commissioning rather than assuming. Second, and this is the one that gets skipped: PTP carries a clock-quality / clockClass field, so consume it. When the grandmaster drops to holdover it degrades its advertised clockClass, and a slave (or your SCADA) can act on that — flag the timestamps as reduced-accuracy, or at least log it. A time-sync system that can't tell you when it stopped being accurate is a system that will hand you confidently wrong timestamps during the one event you built it for.

A default that's right most of the time

If you're standing up a plant-wide SCADA network with polled data and server-side timestamping — water, general manufacturing, most process plants — run NTP to a stratum-1 source (a GPS-disciplined NTP appliance is cheap), point every server, PLC, and HMI at it, and move on. Verify the offset once with ntpq -p or the vendor's equivalent, confirm nobody's silently falling back to their own free-running RTC, and you're done. Save PTP for where the physics demands it: protection, SOE that has to hold across devices to 1 ms, and 61850 process bus. Buying microsecond time for millisecond-fuzzy data is a cost with no signal behind it — and every boundary clock and grandmaster you add is another thing that fails at 3 a.m.

The check that catches both mistakes is the same one: on the SCADA server, diff its clock against an independent reference during a known event, and look at where the timestamps on a real SOE record actually land. If they line up to well inside a millisecond and you're only doing polled data, you over-bought. If they wander by tens of milliseconds and someone's relying on cross-substation event ordering, you under-bought. The number, not the spec sheet, tells you which system you actually have.