PTP Archives - Telnet Networks

Addressing 5G Timing Challenges with Timebeat: What Canadian Carriers Can Fix at the Source

Most 5G timing challenges trace back to one rule. Canada’s mid-band 5G, in the 3500 MHz and 3800 MHz bands, uses time division duplex (TDD): neighbouring cells share a frequency and take turns, all transmitting together and then all listening together. 3GPP puts a number on how closely they must agree. Cells on the same frequency with overlapping coverage must start their frames within 3 microseconds of each other, which ITU-T interprets as ±1.5 µs against a common reference such as UTC.

The rule doesn’t stop at your own network. ISED’s technical rules for these bands, SRSP-520, require licensees running unsynchronized TDD in adjacent blocks of the same area to coordinate with each other when their emissions cross set thresholds. Synchronized operation, with frames starting together and the same uplink and downlink periods, is one of the coordination techniques it names. In practice, time is part of how Canadian operators coexist.

That ±1.5 µs is often quoted as if it belonged to the timing equipment. It doesn’t. In ITU-T’s own worked example, the grandmaster gets 100 nanoseconds of it, the radio keeps 400 ns for itself, and the transport network in between gets everything else.

So here is the limitation up front: no grandmaster, Timebeat’s included, can buy back budget that the transport network has already spent. What a grandmaster platform can do is make sure the source never becomes the problem, hold the line when GNSS disappears, and show you where the rest of the budget is going. Those are the challenges this post covers, and they are where Timebeat, our precision timing partner, has focused its engineering. If you’d like the fundamentals first, our earlier primer on precision timing in 5G and O-RAN networks covers them. This post is written for the people who design and run timing in national carrier networks.

Which standard says what

A lot of 5G timing conversations go sideways because the standards get blended together. A datasheet line such as “G.8275.1 compliant” is often read as a statement about accuracy. It isn’t. G.8275.1 is the PTP telecom profile: the rules for how timing messages are carried. The accuracy limits live in other documents.

Document	What it defines	The number that matters
3GPP TS 38.133	Cell phase synchronization for TDD	3 µs between overlapping cells on the same frequency
3GPP TS 38.104	Time alignment error between a base station’s transmitters	65 ns for MIMO; 260 ns for intra-band contiguous carrier aggregation (FR1)
ITU-T G.8271	Time and phase accuracy classes	Class 4: ±1.5 µs, which covers NR TDD
ITU-T G.8271.1	Network limits with full timing support	1.1 µs at the network’s output to the radio; 1.5 µs once the radio’s own error is added
ITU-T G.8272	Primary reference time clock (PRTC)	PRTC-A within 100 ns of UTC; PRTC-B within 40 ns
ITU-T G.8273.2	Boundary and slave clock performance	Maximum time error per clock of 100 ns (Class A), 70 ns (Class B) or 30 ns (Class C)
ITU-T G.8275.1	The PTP telecom profile	Layer 2 Ethernet multicast, with a PTP-aware clock at every hop

Two of those rows are where the hard engineering happens: the network limit, and the clocks that consume it.

Challenge 1: The transport network spends most of the budget

G.8271.1 includes a worked example of how the 1.5 µs is divided along a chain of Class A boundary clocks:

100 ns for the PRTC and grandmaster
550 ns for the constant time error of the clocks in the chain
200 ns for the chain’s dynamic noise
250 ns for link asymmetry

That reaches 1,100 ns at the network’s output. The radio then takes 250 ns to absorb reference rearrangements and 150 ns for its own noise, for 1,500 ns in total.

Two things fall out of that arithmetic.

First, asymmetry is the line item that breaks most often. PTP assumes the path to the grandmaster and the path back take the same time. When they don’t, half the difference becomes time error that PTP cannot detect on its own. Two microseconds of uncompensated asymmetry, from unequal fibre lengths in a pair, a transponder, or a protection switch that sends one direction of a link down a different path, is a full microsecond of error. Most of the network’s allowance, gone in one place.

Second, the tighter radio features shrink everything. Intra-band contiguous carrier aggregation needs the radios involved within 260 ns of each other. Once the radios take their share, G.8271.1 leaves the network roughly 100 to 190 ns, enough for about four to seven Class C boundary clocks between the common clock and the radios. That is one reason carriers move grandmasters closer to the edge, and it comes back in the next challenge.

Fixing this is transport design: full on-path support for G.8275.1, Class C boundary clocks where the budget is tight, enhanced SyncE underneath PTP, and asymmetry measured and compensated link by link. Measuring what a transport network actually does to PTP is a test discipline of its own; we covered fronthaul validation in our Open RAN post with Aukua. Timebeat’s contribution here is narrower, and we’d rather say so: a clean source at the top of the chain, and the visibility to find the link that is eating the budget, which we come to in challenge 4.

Challenge 2: GNSS is a single point of failure, and it’s noisy

Nearly every 5G timing chain begins at a GNSS antenna. That makes GNSS the one input whose failure takes everything downstream with it.

Canada has data on how often that input is disturbed. Researchers at York University and the Canadian Positioning, Navigation and Timing Office ran interference detectors in Vancouver, Montréal and Ottawa for about a year. They found that “GNSS receivers are subjected to a few minutes of interference everyday,” and that “approximately 14% of these events have the potential to cause receivers to lose lock” (Inside GNSS, January 2024). Many of the events carried the signature of personal privacy devices: cheap jammers that are illegal in Canada and in use anyway.

Jamming is the visible failure. The receiver loses lock, raises an alarm, and the grandmaster goes into holdover. Spoofing is worse because nothing alarms. A receiver fed a convincing counterfeit signal locks to it and hands the wrong time downstream as if it were right, and every radio follows. There is no national fallback to lean on either: Canada and the US switched off Loran-C in 2010, and no eLoran service replaced it.

Architecture decides how exposed you are. A centralized design has a few antennas at well-chosen sites that are easy to protect. A distributed design, the one tight carrier aggregation pushes you toward, puts receivers on rooftops across the city, in exactly the environment that study measured.

Timebeat’s answer is layered, and each layer covers a different failure:

Two bands, four constellations. The Open Time Appliance’s u-blox LEA-F9T receiver tracks GPS, Galileo and BeiDou on two frequency bands (L1 with L2 or L5). Dual-band reception corrects ionospheric error, and a jammer that only covers L1 leaves the second band usable.
Authentication. Galileo’s Open Service Navigation Message Authentication (OSNMA), declared operational by the EU Agency for the Space Programme in July 2025, cryptographically signs the navigation message so a receiver can reject data that didn’t come from Galileo. Timebeat implements it twice: in the receiver firmware, and at platform level through a separate authentication feed it calls Trust Bridge.
An independent satellite layer. Timebeat adds Iridium Satellite Time and Location (STL) beneath GNSS. STL is broadcast from Iridium’s low Earth orbit constellation, which Iridium says delivers signals 1,000 times more powerful than GNSS. It works indoors with a small antenna, covers the globe (the far North included), and according to Timebeat delivers time to within 100 ns of UTC on its own. Timebeat cross-validates STL against GNSS and the internal oscillator every second, so a jammed, spoofed or lost GNSS source shows up as a disagreement instead of passing silently.
Quorum. Timebeat’s Shelf puts three independent grandmasters in one rack unit, each with its own oscillator, multi-band receiver, antenna, power feed and PTP output. Software on each unit weighs its own GNSS against PTP from the other two, and the three run active-active with what Timebeat describes as millisecond failover. A quorum, in Timebeat’s words, “tolerates compromise of fewer than half of the participating references.” One bad receiver gets outvoted rather than obeyed.

Each layer has limits, which is why they’re stacked. OSNMA proves Galileo data is genuine, but it doesn’t stop jamming, and on its own it can’t rule out a genuine signal recorded and replayed with a delay. That’s where an independent source earns its place, and STL’s accuracy makes it more than a cross-check: at under 100 ns to UTC, it stays within the 100 ns that ITU-T’s worked example allows for the source, so STL can carry the timing chain while GNSS is down. At sites with heavy interference, an anti-jam antenna is still a separate decision.

Challenge 3: Holdover is a budget, not a feature

When every external reference is gone, the oscillator inside the grandmaster is the only thing keeping time, and its drift spends the budget. Datasheets usually quote holdover against 1 or 1.5 µs over 24 hours. That’s the wrong yardstick for a carrier, because the network has already claimed most of the 1.5 µs. G.8271.1’s worked example sets aside 400 ns for riding out a short GNSS outage.

The Open Time Appliance comes with a choice of three oscillators, and Timebeat publishes a 24-hour holdover figure for each:

Oscillator	24-hour holdover (Timebeat figure)
Quartz DOCXO	±1.5 µs
Rubidium Black	under 500 ns
Rubidium Black+	under 120 ns

Read against a few hundred nanoseconds rather than 1.5 µs, the choice stops being academic. A quartz grandmaster is a sound choice where outages are short and repairs are quick. Where a failed antenna means a truck roll on a winter road, or a flight, rubidium is what keeps the radios inside budget until someone arrives. Treat every vendor’s holdover figure, these included, as a typical value under stable conditions, and ask how long the unit was locked beforehand and at what temperature it was tested. (Our guide to TCXO, OCXO and rubidium oscillators explains why those conditions matter.)

Holdover is also a property of the whole chain, not just the box at the top. ITU-T’s own examples make the point. With ordinary SyncE underneath PTP, G.8271.1 shows a day-long GNSS outage pushing time error at the radio to about 3.5 µs, more than twice the limit. With enhanced SyncE traceable to an enhanced primary reference clock, and Class C boundary clocks throughout, a three-day outage stays inside 1.5 µs. Both are informative examples rather than guarantees, but the direction is clear. The Open Time Appliance supports SyncE as both client and server, so it can take frequency from the network as well as give it. And where STL is fitted, the oscillator doesn’t have to run unaided at all: Timebeat says timing “holds without interruption” when GNSS is jammed, spoofed or lost, with STL keeping the source within 100 ns of UTC.

Challenge 4: Timing fails quietly

A 5G timing fault rarely announces itself as a timing fault. It shows up as interference between neighbouring cells, failed handovers, carrier aggregation dropping users, or throughput sagging in the busiest parts of the city. Each of those has other plausible causes, so a timing problem can spend days being investigated as something else. Timebeat’s co-founder and CTO, Lasse Johnsen, puts it bluntly: “If your NOC discovers a fronthaul timing problem because a customer complains about dropped calls, you have already lost.”

At minimum, a NOC needs to see:

Clock class changes at every grandmaster and boundary clock. That is how a clock tells the network it has lost its reference.
Measured offset at every slave clock, not only the grandmaster’s report that it is locked.
Satellite count and signal quality at every GNSS receiver, to catch interference before it becomes loss of lock.
Best master clock election outcomes, so a failover to a weaker source doesn’t go unnoticed.
History. Timebeat recommends keeping at least 90 days, so a timing event can be lined up against the KPI dip it caused.

This is the layer Timebeat calls Sync Insight. In Timebeat’s words, it monitors “G.8275.1 telecom-profile fabrics … hop by hop” to “detect grandmaster drift, packet delay variation and asymmetry before they degrade carrier KPIs.” It ships with pre-built Grafana dashboards, streams to Elasticsearch and Kafka, raises alerts through PagerDuty, Slack or webhooks, and can be deployed entirely on-premises, which matters to carriers that would rather keep network telemetry in their own data centres. Underneath it, the Timebeat Agent runs on Linux and Windows hosts, uses hardware timestamping on common NICs such as Intel’s E810, and reports 167 telemetry fields.

One habit from our AI campus post still applies: add a few measurement points that sit outside the chain, at aggregation sites and a sample of cell sites, so the evidence that the chain is healthy isn’t only the chain vouching for itself.

The 5G timing challenges at a glance

Challenge	What actually fixes it	Timebeat’s part
The transport spends the budget	Full on-path G.8275.1, Class C boundary clocks, enhanced SyncE, asymmetry measured and compensated	Showing where the budget goes, across third-party boundary clocks too (Sync Insight)
GNSS jamming and spoofing	Several bands and constellations, authentication, an independent source, quorum	Dual-band, four-constellation GNSS; OSNMA; Iridium STL; the Shelf
GNSS outages	Holdover sized to restoration time, frequency support from the network	DOCXO, Rubidium Black or Black+; SyncE client and server
Silent failure	Continuous measurement wired into the NOC	Sync Insight and the Timebeat Agent

Where Timebeat fits in a carrier network

Most national networks end up using two patterns, often side by side.

Centralized: a hardened source at regional sites. A Shelf at an aggregation site or regional point of presence acts as PRTC and G.8275.1 grandmaster, delivering PTP and SyncE into the transport. Timebeat’s hardware supports G.8275.1 with G.8273.2 Class C boundary clock performance, and SyncE to G.8262. Three independent receivers, quorum, rubidium holdover and STL concentrate the resilience in a few well-protected places. The trade-off is that the transport must carry phase to every radio, with short boundary clock chains.

Distributed: grandmasters toward the edge. Single Open Time Appliances go where the transport can’t be trusted to carry phase (leased or third-party backhaul, microwave spurs, rural and northern sites) and where carrier aggregation clusters need the common clock close by. Each unit is small (three fit in one rack unit), the oscillator is chosen to match how long the site might wait for a repair, and STL’s indoor antenna helps where rooftop sky view is poor. More receivers means more exposure, which is the argument for authentication and STL on every one of them.

Sync Insight sits across both, and across the transport vendor’s boundary clocks, so the whole chain reports into one view.

Four questions for your next timing design review

Whichever vendor you choose, these questions separate a timing design from a timing purchase:

What does the grandmaster claim, and what was measured? Its PTP profile, the G.8273.2 class of its PTP ports, its accuracy to UTC from each source it can use, and who did the measuring.
What is the holdover figure measured against? A 24-hour figure against 1.5 µs tells you little if your outage allocation is 400 ns. Ask for the test conditions too.
What happens when GNSS is spoofed rather than jammed? What does the unit detect, what does it advertise downstream, and how quickly does its clock class change?
What can you see that the timing equipment doesn’t report about itself? If the only evidence of a healthy chain comes from the clocks in it, you’ll hear about a fault from the RAN team first.

Talk to us about your 5G timing design

Telnet Networks is Timebeat’s partner in Canada. You can explore the Timebeat range or contact our sales and engineering team directly. To make the first conversation useful, have these ready:

Where your PRTCs and grandmasters sit today, and the number of boundary clock hops to your furthest radio
Which transport segments aren’t PTP-aware end to end, such as leased backhaul, microwave or third-party fibre
The GNSS situation at those sites: rooftop sky view, known interference, indoor-only locations
Your worst-case restoration time for a remote site
What your NOC sees of timing today, and where those alarms go

We’ll come back with where Timebeat fits in your design, and where it doesn’t.

Telnet Networks is a Canadian value-added reseller of synchronized time, network visibility, and test and measurement solutions, and Timebeat’s partner in Canada. Timebeat product figures are Timebeat’s published specifications. Product and service names are trademarks of their respective owners.

Your AI Cluster Doesn’t Need Sub-Nanosecond Timing. Your Campus Does.

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

Are your White Rabbit ports calibrated, and how is the calibration performed and maintained? Uncalibrated White Rabbit is expensive PTP.
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.
What is the holdover specification under realistic thermal conditions, not laboratory conditions? Ask for the temperature stability assumption behind the number.
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.
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.

Everything Network Engineers Need to Know about PTP

Precision Time Protocol (PTP), standardized as IEEE 1588 in 2002, is a network-based protocol that provides highly accurate time across packet-based networks. Designed to overcome the limitations of older protocols like NTP, PTP enables devices to synchronize to a master clock with sub-microsecond precision, ensuring precise event coordination and timestamps. Developed for industries such as telecommunications, finance, power, and broadcasting, PTP has evolved to support advanced applications like 5G, O-RAN, high-performance data centers, and industrial automation, making it essential wherever highly accurate, scalable network-wide timing is critical.

To achieve this level of accuracy across large and complex networks, PTP relies on a structured hierarchy of timing devices. Rather than every device communicating directly with a single time source, PTP distributes time through specialized components that maintain synchronization as it moves through the network. Two of the most important elements in this architecture are grandmaster clocks, which provide the authoritative time reference, and boundary clocks, which help distribute that time while preserving accuracy.

Grandmasters and Boundary Clocks

Grandmaster Clocks

A grandmaster clock is the main source of accurate time in a network, acting as the reference that all other devices, or “slaves,” follow. It provides precise timestamps that devices use to keep their internal clocks in sync. Grandmaster clocks get their time from highly accurate sources like GPS or atomic clocks. By keeping a stable and precise reference, grandmaster clocks make sure all devices in the network stay synchronized, allowing systems to operate reliably and in coordination.

Boundary Clocks

A boundary clock is a network device used in a PTP environment to help distribute accurate time across a network. It synchronizes to an upstream time source, typically a PTP grandmaster clock that may be disciplined by GPS, GNSS, or an atomic reference. The boundary clock receives this precise time on one port, aligns its internal clock, and then redistributes accurate timestamps to devices connected on its other network ports. By correcting for delay and jitter at each interface, it helps keep downstream devices closely synchronized.

Within a PTP timing structure, devices are organized in a hierarchy that protects time accuracy as it moves through the network. The grandmaster sits at the top as the primary time source, while boundary clocks form intermediate layers that receive time, regenerate it, and pass it to additional switches, routers, or end devices. This structure prevents timing errors from accumulating across multiple network hops and helps maintain precise synchronization in large environments such as telecommunications networks, data centers, and industrial systems.

Grandmaster vs Boundary Clock

In a PTP network, the grandmaster clock provides the primary source of accurate time, typically from GPS or atomic clocks, setting the reference for all devices. Boundary clocks distribute this time to multiple devices, reducing network delay errors and maintaining synchronization across large or complex networks.

Feature	Grandmaster Clock	Boundary Clock
Primary Role	Main source of accurate time	Distributes time from a grandmaster to other devices
Connection	Usually connected to GPS, atomic clock, or other precise source	Connects to upstream time source (grandmaster) and downstream devices (time consumers)
Function	Provides authoritative time to the network	Acts as both receiver and sender of time
Network Ports	Typically single port	Multiple ports for distribution
Purpose	Sets the standard for network time	Maintains synchronization and reduces timing errors
Common Use	Provides network-wide reference	Ensures precise timing distribution in large or complex networks

Why Does PTP Matter?

As networks support high-speed trading, 5G, smart grids, and real-time industrial systems, precise, traceable time has become critical. Traditional methods like Network Time Protocol were not designed for microsecond or nanosecond accuracy, and issues like latency variation, jitter, and asymmetrical paths can introduce timing errors. Precision Time Protocol addresses these challenges by compensating for packet delays, providing much greater accuracy across complex Ethernet networks.

PTP allows systems to operate as tightly coordinated units rather than loosely synchronized devices. In telecommunications, finance, broadcasting, and power utilities, even small timing errors can cause data loss, compliance issues, or instability. By delivering deterministic, high-precision synchronization over standard IP networks, PTP solves problems legacy methods cannot, ensuring the performance, reliability, and scalability modern infrastructure requires.

Key Applications of PTP

Telecommunications (4G LTE and 5G)
PTP ensures base stations and core network elements remain precisely synchronized. This timing accuracy is critical for handoffs, spectrum efficiency, and carrier aggregation, directly impacting network reliability and performance.

Financial Services and Trading
PTP provides exact timestamps for every transaction. Accurate timing is essential for regulatory compliance, auditing, and fair execution in high-speed trading environments.

Broadcast and Media Production
PTP synchronizes audio and video streams across all devices and networks. It eliminates drift, ensures lip-sync accuracy, and maintains reliable live and remote broadcasts.

Power and Energy Utilities
PTP aligns clocks across substations and phasor measurement units (PMUs). Precise timing supports accurate grid monitoring, faster fault detection, and stable power delivery.

Industrial Automation and Smart Manufacturing
PTP coordinates robotics, motion control, and sensors. Deterministic timing allows precise operations, improves product quality, and ensures safety in automated systems.

Healthcare and Hospitals

Hospitals rely on PTP to synchronize clinical systems, medical devices, and networks. It ensures accurate timestamps for health records, imaging, labs, and monitoring equipment, supporting patient safety and regulatory compliance.

Beyond PTP – White Rabbit Protocol

For applications requiring synchronization beyond what standard PTP can achieve, the White Rabbit Project extends its capabilities. Combining PTP with Synchronous Ethernet and precise phase measurement, White Rabbit achieves sub-nanosecond accuracy, making it ideal for scientific research, particle accelerators, telescope arrays, and other ultra time-sensitive systems. It delivers deterministic, ultra-precise timing that standard PTP cannot provide, enabling new possibilities for distributed systems that demand extreme coordination.

Feature	PTP (Precision Time Protocol)	White Rabbit Protocol
Typical Accuracy	Microseconds	Sub-nanosecond
Time Distribution	Standard Ethernet	Synchronous Ethernet with phase measurement
Use Cases	Telecom networks, financial trading, broadcasting, industrial automation	Particle accelerators, telescope arrays, high-energy physics experiments, quantum networking and computing
Network Requirements	Standard Ethernet	Ethernet with precise timing support
Determinism	High	Ultra-high
Scalability	Enterprise and industrial networks	Specialized high-precision networks

PTP Risks and Limitations

While Precision Time Protocol delivers high-precision synchronization, real-world networks can introduce challenges that limit its accuracy. Variable network delays, asymmetrical paths, and jitter can cause timing errors, especially in complex or heavily loaded networks. Hardware limitations, such as network switches or routers that do not fully support PTP, can further degrade performance. Additionally, maintaining PTP across wide-area networks (WANs) or mixed-vendor environments can be difficult due to compatibility and interoperability issues.

To address these challenges, several solutions are being implemented. Boundary and transparent clocks help compensate for network-induced delays, while hardware-assisted timestamping improves accuracy at the device level. Standards and profiles are evolving to improve interoperability across devices and vendors, making it easier to achieve consistent precision even in complex real-world deployments.

PTP Appliance Vendors

Across North America, several vendors provide high-quality PTP timing appliances such as grandmaster clocks, boundary clocks, and full time distribution systems. These solutions form the backbone of precision synchronization in telecom, finance, industrial, and critical infrastructure networks.

Key players include Microchip Technology Inc., which offers modular grandmaster systems designed for 5G and enterprise timing; Meinberg, known for its comprehensive line of GNSS-synchronized PTP appliances; and EndRun Technologies, which provides highly accurate grandmaster clocks capable of nanosecond-level performance. Alongside these established global vendors, specialized providers support diverse deployment needs with solutions tailored for mission-critical and complex networks.

Safran offers SecureSync based grandmaster clocks and time servers with microsecond‑level PTP precision and resilient GNSS disciplining. Their appliances support multi‑protocol outputs and White Rabbit extensions, making them suitable for regulated, mission‑critical environments where reliability and security are key.

Bodet delivers modular PTP/NTP grandmasters and boundary clock systems designed for enterprise, healthcare, transportation, and industrial applications. Bodet units provide cost efficient functionality and capabilities that ensure accurate distribution across complex networks.

TimeBeat focuses on scalable, resilient timing appliances that support high‑precision PTP distribution, robust GNSS disciplining, and enhanced architecture options for redundancy and long‑term stability. Their products are geared toward modern network timing needs where precision and uptime are critical.

Vendor	Key Solutions	Typical Use Cases
Safran	SecureSync-based grandmaster clocks and time servers	Regulated and mission-critical environments requiring high reliability and security
Bodet Time	Netsilon 9 and 11 Modular PTP/NTP grandmasters and boundary clock systems	Enterprise, healthcare, transportation, and industrial networks
TimeBeat	Standalone PTP timing appliances and PCIe server cards	Modern networks where precision timing and uptime are critical

Together, these vendors provide a range of timing sources from rugged edge devices to carrier‑grade grandmasters, giving network architects options that match their performance, scalability, and deployment requirements.

If Precision Time Protocol is something you are considering for your network, now is a great time to start the conversation. Whether you are planning a new deployment, upgrading your timing infrastructure, or simply exploring how PTP could improve accuracy and performance, our team is here to help. Contact our sales team to discuss your requirements and find the right solution for your environment.

PTP Time Synchronization

Unparalleled Efficiency At Scale With SecureSync In Data Operations

Introduction

In the era of big data and distributed systems, achieving efficiency at scale is crucial for data operators. The Safran SecureSync emerges as a game-changing solution, providing unparalleled efficiency and reliability in time synchronization for data operations. We will explore the technical details behind the SecureSync and demonstrate how data operators can gain significant efficiencies at scale by leveraging its advanced features.

Exceptional Precision and Reliability

The SecureSync boasts exceptional precision and reliability, ensuring accurate time synchronization across distributed systems. Its innovative architecture combines precision timing components and advanced technologies, delivering ultra-low phase noise and frequency accuracy. With a holdover stability of <1 µs/day, the SecureSync guarantees uninterrupted synchronization, even in the event of temporary loss of reference signals.

High Scalability and Flexibility

Data operators often deal with expanding infrastructures and evolving requirements. The SecureSync is designed to address these scalability challenges. It supports a high number of simultaneous network clients, accommodating large-scale distributed systems effortlessly. Whether deployed in a small cluster or a global network, the SecureSync seamlessly integrates with existing infrastructure, providing precise time synchronization across all nodes.

Robust Timing Redundancy

The SecureSync ensures reliability in demanding operational environments through its timing redundancy capabilities. It incorporates dual-redundant power supplies and accepts multiple timing sources, minimizing the risk of single points of failure. Redundant timing sources and power supplies guarantee continuous synchronization and prevent disruptions that could impact data operations.

Advanced Network Time Protocol (NTP) and Precision Time Protocol (PTP) Support

SecureSync supports both NTP and PTP, enabling compatibility with a wide range of distributed systems. NTP provides accurate time synchronization for applications that require millisecond-level accuracy, while PTP offers sub-microsecond synchronization for applications with stringent timing requirements. The SecureSync’s ability to support both protocols ensures flexibility in integrating with various data operations, optimizing performance and efficiency.

Compliance and Traceability

Data operators often face stringent compliance requirements and the need for traceability in their operations. The SecureSync addresses these concerns by adhering to industry standards for time synchronization. It provides traceable and auditable event timestamps, facilitating compliance with regulatory frameworks and simplifying the audit process for data operations.

Comprehensive Management and Monitoring Capabilities

To efficiently manage and monitor distributed systems, the SecureSync offers advanced management and monitoring features. Its intuitive web-based interface allows for centralized control, configuration, and monitoring of multiple SecureSync units. The interface provides real-time status updates, performance metrics, and alerts, ensuring proactive management and facilitating rapid troubleshooting.

Conclusion

The SecureSync from Safran empowers data operators to achieve unparalleled efficiency at scale in their distributed systems. With exceptional precision, scalability, redundancy, protocol support, compliance adherence, and comprehensive management capabilities, the SecureSync proves to be a reliable and efficient solution for accurate time synchronization.

By leveraging the technical capabilities of the SecureSync, data operators can ensure seamless data operations, mitigate risks of inconsistencies, and optimize performance at scale. With its advanced features and robust design, the SecureSync emerges as a key enabler for data operators seeking efficiency, reliability, and compliance in their distributed data environments.

NTP PTP SecureSync Time Synchronization