Precision Timing in the Real World

Lessons from Low-Latency Exchange Architect Dave Beattie

When people talk about time synchronisation, they often jump straight to technology. NTP. PTP. White Rabbit. Nanoseconds.

But according to Dave Beattie, Solutions Architect specialising in low-latency exchange infrastructure, that’s the wrong place to start.

“Timing isn’t really about absolute accuracy,” Dave says. “It’s about agreement. Systems agreeing with each other matter far more than being perfectly aligned to UTC.”

After years of designing timing and network architectures for enterprises, broadcasters, and financial exchanges, Dave has seen first-hand how timing moves from a background utility to a mission-critical system — and how easily organisations overcomplicate it.

We sat down with him to talk about what’s changed, where teams go wrong, and how to think about timing practically.

From NTP to PTP: Why Timing Became Business-Critical

A decade ago, most enterprises relied on NTP. With careful design, you could reach sub-millisecond performance. For many environments, that was enough.

But trading systems changed the equation.

As exchanges sped up and regulations like MiFID II demanded tighter timestamping, milliseconds became microseconds — then nanoseconds.

At that scale, timing isn’t about “roughly right.” It’s about determinism.

“If two trades hit two different gateways at almost the same time,” Dave explains, “you must be able to prove which one arrived first. There’s real money tied to that order of events.”

This is where PTP became the commercial standard. It was able to take advantage of:

• Hardware timestamping

• Kernel-bypass

• Advanced client software

• Deterministic network transport

Producing nanosecond-class precision.

The Biggest Mistake Teams Make

Ask most organisations what accuracy they need and the answer is predictable:

“As accurate as possible.”

That sounds sensible. It doesn’t.

“It doesn’t help anyone,” Dave says. “You can always build something more accurate, but you’ll spend a fortune and probably solve the wrong problem.”

Instead, timing should start with failure scenarios:

• What breaks if time is wrong?

• By how much?

• For how long?

Only then can you design an architecture that’s fit for purpose.

For many exchanges, ±100 nanoseconds from UTC is sufficient. Going beyond that often adds cost without delivering real business benefit.

Why ‘Agreement’ Beats ‘Accuracy’

One of Dave’s strongest points is surprisingly counter-intuitive.

Absolute time accuracy is often less important than consistency.

“If every server is wrong by the same amount, that’s usually fine. If they disagree with each other, that’s when you’re in trouble.”

Chronology — the exact order of events — matters more than perfect UTC alignment.

That insight shapes architecture decisions. It’s better to present all clients with one trusted time source than have each node interpret multiple sources independently.

The Silent Killer: Asymmetry

Even experienced teams underestimate one factor: latency asymmetry.

PTP assumes forward and return paths are symmetrical. In real networks, they rarely are.

Speed mismatches, store-and-forward behaviour, queueing differences — all create hidden offsets.

And the worst part?

“You won’t see it,” Dave says. “It’s silent.”

Half the asymmetry error becomes your time offset.

Which is why:

• symmetric paths

• controlled switching

• predictable forwarding

matter just as much as fancy hardware.

When PTP Isn’t Enough

Standard PTP gets you far. But it has limits.

Boundary clocks can introduce variance at each hop. Client hardware can add jitter. In practice, Dave sees around 3–5 ns as the floor for conventional PTP systems.

Below that, you need tighter coupling.

That’s where White Rabbit comes in.

By synchronising frequency at layer 1 using SyncE, White Rabbit can push nodes into sub-nanosecond alignment.

But it’s not a universal solution.

“It makes sense inside data centres or tightly controlled environments,” Dave says. “It’s much harder across WANs or provider networks.”

His advice is simple: only adopt it when requirements demand it.

If you’re happy at 100 ns today, chasing 1 ns is probably unnecessary engineering.

What Makes Timing Easy to Buy

From a buyer’s perspective, timing projects succeed when they feel predictable.

Not flashy hardware. Not theoretical precision.

What matters is:

• Proven architectures

• Clear design documentation

• Known outcomes

• Measurable performance

“People want to understand the full solution,” Dave says. “Not just a box.”

Confidence beats novelty every time.

Looking Ahead

So what changes next?

Dave doesn’t expect requirements to keep tightening forever. There’s a practical limit.

Instead, the next wave is about usability:

• better monitoring

• clearer reporting

• easier proof of compliance

• end-to-end visibility

In other words, operational confidence.

Timing shouldn’t just work. It should be provable.

Final Advice for CTOs and Infrastructure Leaders

If Dave could give one piece of advice, it’s this:

Start with requirements. Design for failure. Plan for proof.

And remember:

“The absolute time matters less than collective agreement. If everything moves together, you’re fine. If systems disagree, that’s when problems start.”

About Dave Beattie 

Dave Beattie is a Solutions Architect specialising in low-latency exchange infrastructure, with experience spanning enterprise networking, broadcast environments, and financial trading systems. He has designed timing architectures for major exchanges and continues to advise organisations on building resilient, practical synchronisation strategies.