Timing architecture for the AI campus, and where White Rabbit actually belongs.

Every timing vendor now has an AI page. Most of them make the same claim: sub-nanosecond synchronization will make your GPU cluster faster.

It won’t.

That is an uncomfortable sentence to write for a company that sells precision timing equipment, so let’s be precise about why it’s true, and then get to the part that matters. There is a real and growing timing requirement in AI infrastructure. It just isn’t where it’s being sold.

The claim that doesn’t hold up

The pitch goes something like this: a training job across thousands of GPUs is bottlenecked by synchronization overhead, clock skew compounds that overhead, therefore tighter clocks mean faster training.

The first half is true. The second half doesn’t follow.

Collective operations are the synchronization mechanism in distributed training. An all-reduce, an all-gather, a barrier: these block on data arrival and on completion signals from peer ranks. They do not consult the system clock. A GPU waiting at a barrier is waiting for its slowest peer to finish computing and for the network to deliver the result. It is not waiting because two nodes disagree about what time it is.

You can hand a training job a cluster with fifty microseconds of clock offset between nodes and the throughput will be unchanged. The real causes of collective overhead are well understood and none of them are wall-clock related: congestion and incast on the fabric, stragglers caused by thermal throttling or a bad link, suboptimal collective algorithm selection for the topology, and PCIe or NVLink contention on the host.

So when you see a claim that better clocks recover stranded GPU capacity, be skeptical. The underperformance is real. The attribution is not.

That matters commercially, because a timing project justified on a throughput claim will be measured against a throughput result, and it will fail that measurement. A timing project justified correctly will not.

What precise time is actually doing in an AI cluster

Time in a large training cluster is an observability and coordination primitive, not a performance primitive. Four uses carry real weight.

Cross-node profiling and causal ordering. This is the strongest and best-documented case, and notably it comes from the compute side rather than from timing vendors. NVIDIA’s engineers presented exactly this argument at the 2026 Workshop on Synchronization and Timing Systems: standard profiling techniques struggle in distributed settings because timestamps from different nodes cannot be trusted relative to one another. Without a common time base you cannot say whether node 412 stalled because node 87 was late, or the reverse. With one, you can order events causally across the whole cluster and find the actual origin of a straggler. Their stated requirement is PTP and unified timestamp alignment, not sub-nanosecond.

Congestion and telemetry correlation. One-way delay measurement, queue occupancy sampling, and flow telemetry are only interpretable if the timestamps at both ends of a measurement share a reference. As fabrics adopt more aggressive congestion control and, increasingly, time-referenced scheduling, this dependency deepens.

Storage and checkpoint consistency. Distributed checkpointing, log ordering across a namespace, and post-incident reconstruction all degrade when clocks disagree by more than the interval between events you care about.

Forensics and accountability. When a multi-week training run fails at hour 300, the reconstruction is a timeline. A timeline assembled from clocks that were never synchronized is a guess.

None of those four require picoseconds. They require a common, provable, well-characterized time base across every node in the estate. That is a different engineering problem, and it gets harder in a specific place.

The requirement moves to the campus

Inside a single fabric, this is largely a solved problem. Modern data centre switches and NICs do hardware timestamping, and PTP running over a fabric with boundary clocks and SyncE frequency support will hold nodes within tens of nanoseconds of each other. The fabric vendors ship it. If your AI deployment is one hall in one building, buy a competent grandmaster pair, enable PTP properly, monitor it, and move on.

The difficulty starts when the deployment stops being one hall.

AI buildouts are outgrowing single rooms faster than any previous class of infrastructure. Power and cooling constraints push a cluster across multiple halls, then multiple buildings on a campus, then multiple sites in a metro. Distributed training across sites is no longer exotic. The moment your time distribution has to traverse hundreds of metres or tens of kilometres of fibre, the dominant source of error changes.

PTP calculates the offset between master and slave by assuming the path delay is symmetric: that a packet takes the same time to travel in each direction, so the round trip can be halved. On a short link inside a rack, the error introduced by that assumption is small. On a long fibre run, it is not. Different fibre lengths in each direction of a pair, different wavelengths with different propagation velocities, asymmetric amplification or dispersion compensation, and asymmetric paths through a DWDM system all introduce error that PTP cannot see and therefore cannot correct. It shows up as a fixed offset, it does not average out, and it is invisible to a monitoring system that only reports PTP’s own estimate of its accuracy.

This is the failure mode that gets discovered late, usually during an incident, when two buildings’ logs cannot be reconciled and nobody can explain why.

Why White Rabbit solves that specific problem

White Rabbit is usually introduced by its headline number, sub-nanosecond accuracy, which is the least useful way to understand it. The better framing: White Rabbit is an asymmetry-correction technology that happens to be very accurate as a consequence. It began at CERN as a way to synchronize accelerator instrumentation, and the design has been open from the start, which is part of why it has survived the move out of the physics community.

It combines three things. Synchronous Ethernet distributes frequency over the physical layer, so every node in the chain runs on a common frequency rather than a free-running local oscillator. Phase tracking in hardware measures the phase relationship of the recovered clock precisely. And the link is calibrated, meaning the fixed asymmetry of the specific fibre and the specific transceivers is measured and compensated rather than assumed away.

That third element is the one that matters for a campus. White Rabbit does not estimate the path delay and hope it’s symmetric. It knows what the path does.

Two developments make this more relevant than it was five years ago, when White Rabbit was mostly a particle-physics and financial-trading technology. First, it is now standardized: the High Accuracy profile in IEEE 1588-2019 is White Rabbit, which moves it from a specialist implementation into the mainstream timing standard. Second, it is multi-source, with Safran and Timebeat shipping commercial products. Neither of those was true in 2019.

We wrote about the same shift from a different angle when White Rabbit started moving out of the lab and into quantum networking. The AI campus is the same story with a larger budget attached.

The GNSS problem nobody budgets for

There is a second argument for a calibrated fibre timing spine that has nothing to do with AI, and in many deployments it is the one that actually releases budget.

Almost every timing architecture in the field terminates in a GNSS antenna on a roof. That antenna is a single point of failure with a long list of ways to fail: roof access and lease restrictions, cable runs that exceed distance limits, lightning, water ingress, construction blocking the sky view, and, increasingly, deliberate interference. GNSS jamming and spoofing have moved from a theoretical concern to a documented and regularly reported one, and regulators in several jurisdictions are now treating timing resilience as critical infrastructure policy rather than an engineering preference.

The standard answer is holdover: put a good oscillator in the grandmaster and let it coast. A rubidium or double-oven oscillator will hold a few hundred nanoseconds over a day under favourable conditions, and considerably less well in a room whose temperature is being modulated by a GPU cluster’s thermal cycling.

A calibrated fibre link from a site that still has a good reference is a fundamentally better answer than coasting. It is not holdover, it is an alternate path to real time, and it can be engineered to survive the loss of GNSS at any individual site. For any operator running more than one facility, this converts White Rabbit from an accuracy purchase into a resilience purchase, which is a much easier line item to defend.

The reference architecture

The architecture that follows from all of this is layered, and the important design decision is knowing where each layer stops.

Building 2 in the diagram carries no GNSS antenna. It is referenced entirely over the spine, and its clock quality is indistinguishable from the buildings that do have one.

Layer	Function	Technology	Practical target
Reference	Traceable UTC, multiple independent sources	GNSS (multi-constellation) at two or more sites, disciplined oscillator, optional external reference	Traceability and diversity, not accuracy
Spine	Site-to-site and building-to-building distribution	White Rabbit over dedicated calibrated fibre, SyncE frequency	Sub-nanosecond, asymmetry compensated
Building	Local grandmaster function per building or hall	PTP grandmaster fed by the WR node via 1PPS and 10 MHz	Low tens of nanoseconds
Fabric	Distribution into the compute network	IEEE 1588v2 or G.8275.1, boundary clocks, hardware timestamping	Tens of nanoseconds node to node
Host	Local clock discipline on GPU, storage and head nodes	PTP client with hardware timestamping on the NIC	Tens to low hundreds of nanoseconds
Assurance	Continuous verification of the whole chain	Independent monitoring, topology view, historical replay	Provable, not assumed

Two boundaries deserve emphasis.

White Rabbit stops at the building. It requires calibrated ports, SyncE support and specific hardware at both ends of every link. Your Spectrum or Tomahawk fabric does not speak it, and neither does the NIC in a GPU node. Sub-nanosecond timing to a GPU is something that does not exist in shipping hardware. The value of the spine is that everything downstream of it starts from a reference that is correct, common across all buildings, and independent of any single antenna.

The assurance layer is not optional, and it is the layer most often omitted. A timing chain that is not independently monitored is a timing chain you will discover is broken during an outage. The monitoring has to observe the actual delivered time at the hosts, not merely report that the grandmaster believes itself to be locked.

Sidebar: What this looks like built on Timebeat

Timebeat is worth working through as a concrete example, because their product line happens to span the full stack described above, which makes the layer boundaries easy to see. The same architecture can be built from other vendors’ components; the point is the shape, not the badge.

Reference layer. An Open Time Appliance at each of two or more sites provides the GNSS-disciplined reference. It is a 1U platform with GNSS inputs, three oscillator grades — from a 1.5 µs quartz DOCXO up to the elite Rubidium Black+. Two of them at separated sites, with independent antenna installations, gives you reference diversity before you have spent anything on the spine.

Spine layer. An Open Time Node WR in each building carries the White Rabbit links. It is a 1U-mountable node, up to three per chassis, delivering sub-nanosecond accuracy over calibrated fibre and, critically, able to operate without a local GNSS reference. That last property is the whole argument for the spine: a building with no roof access and no antenna still gets a reference indistinguishable in quality from a building that has one. For organizations integrating timing into their own platforms rather than buying appliances, the White Rabbit Mezzanine provides the same capability as an OEM module with four SFP cages, 1PPS and 10 MHz inputs and outputs, and a dedicated calibration port.

Building and fabric layers. The WR node hands off to conventional PTP through 1PPS and 10 MHz outputs into the local grandmaster function, and from there the fabric runs standard IEEE 1588v2 or G.8275.1. Nothing exotic is required of the switches beyond the boundary clock and hardware timestamping support they already have. This is the handoff point, and drawing it explicitly in a design document is what keeps a timing project honest.

Host layer. The Timebeat agent is a single binary per host, Linux or Windows, that auto-discovers timing hardware and disciplines the local clock. It supports 1588v2, G.8275.1, SMPTE 2059-2 and AES67, and it can consume multiple PTP masters, NTP servers and GNSS receivers simultaneously, rejecting sources that degrade. It runs on the common enterprise distributions as well as in Docker and Kubernetes, which matters when the compute estate is orchestrated rather than hand-built. A jitter attenuation engine filters the raw timestamp stream rather than passing servo noise straight into the system clock.

Assurance layer. Agents stream metrics over gRPC with mutual TLS to a dashboard that shows topology, live metrics and historical replay across every clock and PTP domain. REST and gRPC APIs expose every metric, alert and configuration item, with export into Grafana, Datadog or Splunk rather than a demand that you adopt yet another console. Self-hosted, managed and air-gapped deployment options exist, the last of which is usually the deciding factor in defence and classified environments.

Why the single-vendor view is worth something here. The hard part of operating this architecture is not any individual layer, it is proving the chain end to end when something goes wrong. Being able to see the White Rabbit spine and the PTP fabric and the delivered host clock in one topology view, with historical replay, converts a multi-day finger-pointing exercise into a query. That is an operational argument rather than a technical one, and it is usually the one that survives contact with the people who will run the system.

Five questions to ask any timing vendor

1. Are your White Rabbit ports calibrated, and how is the calibration performed and maintained? Uncalibrated White Rabbit is expensive PTP.
2. Does the implementation conform to the IEEE 1588-2019 High Accuracy profile? This determines whether you can mix vendors later or have bought a single-source dependency.
3. What is the holdover specification under realistic thermal conditions, not laboratory conditions? Ask for the temperature stability assumption behind the number.
4. What exactly happens when GNSS is lost at one site, and at all sites? The answer should describe a topology change, not just an oscillator coasting.
5. Where does your solution stop, and what carries time the rest of the way to the host? A vendor that cannot draw this boundary clearly has not thought about your deployment.

The point

Timing has quietly become an architecture decision in AI infrastructure, and architecture decisions have to be made at design time. Retrofitting a calibrated timing spine into a campus after the fibre has been pulled, the buildings commissioned and the antenna budget spent is expensive and sometimes impossible.

It is worth being clear about what this buys you, because the honest version is more persuasive than the marketing version. It will not make your training jobs faster. It will make your cluster debuggable, your telemetry trustworthy, your incident timelines defensible, and your entire estate independent of any single antenna on any single roof. For a facility whose compute is worth more per rack than anything that came before it, those are not small things.

---

Telnet Networks designs and supplies precision timing and synchronization solutions for data centre, research, defence and enterprise networks across Canada. If you are planning a multi-building or multi-site AI deployment, we offer a timing architecture review that covers reference diversity, distribution design, GNSS resilience and the assurance layer. Get in touch to arrange one.

More from Telnet Networks

• Everything Network Engineers Need to Know about PTP: the protocol fundamentals behind the fabric layer in this article
• Network Time Synchronization: A Complete Guide: NTP, PTP and where each one belongs
• The Heartbeat of Quantum: How White Rabbit Synchronization is Moving Innovation from the Lab to the Network
• Precision Time Servers and Master Clocks: our timing solutions overview
• Timebeat: advanced clock synchronization and Safran precision time solutions
• GNSS interference detection and mitigation