When Milliseconds Are Not Good Enough

For most things, milliseconds are fine

It's worth being honest up front: most computer systems run perfectly well on millisecond-class clock synchronisation, and pushing past that boundary is operational complexity for no benefit. NTP from a corporate time server, configured by default, gives every machine on a normal enterprise network clocks within a few milliseconds of UTC. Web servers don't care. Application backends don't care. Log aggregators don't care. Certificate validity windows don't care. Database transaction timestamps mostly don't care.

If you can't think of a specific downstream consumer that would notice the difference between two events happening one millisecond apart and two events happening 100 microseconds apart, you don't need precision timing. Run NTP, configure it properly, monitor it for drift, and spend the engineering time on something that produces a measurable improvement in something the business cares about. This article is not an argument for precision time everywhere.

But the list of things that aren't most things is growing

Over the past decade, the population of systems that genuinely need sub-millisecond clock synchronisation has expanded dramatically. Some of this expansion is regulatory; some is technological; some is the natural consequence of operations being run at scales where small clock skew compounds into operational pain. The result is that an increasing number of organisations are discovering that they sit on the wrong side of the millisecond boundary, often without having explicitly noticed when they crossed it.

Six use cases where milliseconds are no longer enough

These are the six most common situations where we see organisations cross the line between "NTP is fine" and "we need PTP". Most organisations cross the line for one of these reasons. Some cross it for several at once.

• ●Regulated financial timestamping. MiFID II RTS 25 requires high-frequency trading timestamps within 100 microseconds of UTC, traceable. FINRA's Consolidated Audit Trail and SEC Rule 613 demand similar discipline in the US. The regulator's view is that NTP is not sufficient evidence — the entity has to be able to demonstrate the synchronisation chain to a primary reference, which means PTP and hardware grandmasters.
• ●Broadcast IP video infrastructure. SMPTE ST 2110 production over IP requires frame-accurate alignment of video, audio and ancillary data essences across the entire facility. The synchronisation budget is roughly one microsecond between any two devices. Black-and-burst analogue reference is gone; PTP is the only credible substitute.
• ●5G fronthaul timing. The ITU-T G.8275.1 profile, which 3GPP recommends for 5G fronthaul, sets a Class 6 time-error budget of ±1.5 microseconds end to end between any two coordinated radios. Massive MIMO, beamforming and inter-cell coordination all depend on this budget being met every second of every day.
• ●AI training collective communication. Large training jobs running across thousands of GPUs are bottlenecked by collective communication operations (all-reduce, all-gather) that synchronise gradients across the cluster. The performance of the training job is dominated by how well-coordinated the participating GPUs are at the network level. As model sizes grow into the trillion-parameter range, the cumulative cost of millisecond-class skew across collective operations becomes significant.
• ●Distributed database consistency. Cockroach DB, Spanner, FoundationDB and other tightly-consistent distributed databases use clock skew bounds to optimise transaction commit ordering. Tighter clocks allow tighter consistency guarantees with lower coordination overhead. Spanner famously runs on a global PTP-disciplined timing fabric for exactly this reason.
• ●Audit trails for regulated activities. Beyond finance, regulated activities in pharmaceuticals, energy trading, telecommunications and defence all increasingly require audit trails with timestamps traceable to UTC at microsecond precision. The regulator's question is always the same: "can you prove that A happened before B?" The honest answer requires precision better than the events are spaced apart.

How to tell if you've crossed the line

There is a single concrete signal that an organisation has crossed from millisecond territory into microsecond territory: a downstream system, a regulator, or a measurement starts failing because two events were ordered wrong. The failure usually shows up first as something subtle — an inconsistent log correlation, a database transaction whose ordering causes an unexpected serialisation, a video alignment artifact that nobody can quite explain — and the team initially attributes it to something else. When the team finally traces the root cause to clock skew between two systems, the question of whether NTP is good enough has been answered for them.

If you can think of a specific downstream system in your stack that depends on event ordering being correct and where being wrong has a measurable cost — money, regulatory exposure, customer experience, operational time — and you can't currently prove that your clocks are tight enough to guarantee the ordering, you have crossed the line. Run an audit on your timing infrastructure before the failure surfaces in front of a customer or a regulator.

What to do about it

If your application has crossed the line, the path forward is well-trodden and the technologies are mature. You need a hardware grandmaster (probably two for redundancy), you need a PTP-aware network between the grandmaster and the systems that consume time, you need hardware-timestamping NICs on those systems, and you need an observability layer that lets the operations team see clock health in real time. The TimeBeat platform provides all four components; so do several other vendors. The harder question is the operational discipline of running the timing infrastructure as a continuously monitored production service rather than installing it and forgetting it.

If your application has not crossed the line, don't deploy precision timing infrastructure. NTP is a fine answer for almost everything, and the engineering effort of running PTP unnecessarily is real. Make the decision based on the actual downstream consumers of your timestamps, not on the marketing material of timing vendors who would like everyone to need PTP.