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.

DocumentWhat it definesThe number that matters
3GPP TS 38.133Cell phase synchronization for TDD3 µs between overlapping cells on the same frequency
3GPP TS 38.104Time alignment error between a base station’s transmitters65 ns for MIMO; 260 ns for intra-band contiguous carrier aggregation (FR1)
ITU-T G.8271Time and phase accuracy classesClass 4: ±1.5 µs, which covers NR TDD
ITU-T G.8271.1Network limits with full timing support1.1 µs at the network’s output to the radio; 1.5 µs once the radio’s own error is added
ITU-T G.8272Primary reference time clock (PRTC)PRTC-A within 100 ns of UTC; PRTC-B within 40 ns
ITU-T G.8273.2Boundary and slave clock performanceMaximum time error per clock of 100 ns (Class A), 70 ns (Class B) or 30 ns (Class C)
ITU-T G.8275.1The PTP telecom profileLayer 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:

Oscillator24-hour holdover (Timebeat figure)
Quartz DOCXO±1.5 µs
Rubidium Blackunder 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

ChallengeWhat actually fixes itTimebeat’s part
The transport spends the budgetFull on-path G.8275.1, Class C boundary clocks, enhanced SyncE, asymmetry measured and compensatedShowing where the budget goes, across third-party boundary clocks too (Sync Insight)
GNSS jamming and spoofingSeveral bands and constellations, authentication, an independent source, quorumDual-band, four-constellation GNSS; OSNMA; Iridium STL; the Shelf
GNSS outagesHoldover sized to restoration time, frequency support from the networkDOCXO, Rubidium Black or Black+; SyncE client and server
Silent failureContinuous measurement wired into the NOCSync 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:

  1. 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.
  2. 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.
  3. 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?
  4. 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:

  1. Where your PRTCs and grandmasters sit today, and the number of boundary clock hops to your furthest radio
  2. Which transport segments aren’t PTP-aware end to end, such as leased backhaul, microwave or third-party fibre
  3. The GNSS situation at those sites: rooftop sky view, known interference, indoor-only locations
  4. Your worst-case restoration time for a remote site
  5. 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.

Replacing Your Spectracom TimeView 400 Clocks: Options, Differences and How to Plan the Switch

log header for Spectracom TimeView 400 replacement: a digital wall clock fed over NTP and PoE from a master clock that stays in place.

Most people start looking into a Spectracom TimeView 400 replacement for one of three reasons: a clock has gone dark, its seconds won’t stop flashing, or someone has just told them spares are hard to find. TimeView 400 displays have hung in dispatch centres, control rooms, broadcast facilities and hospitals since the early 2000s (the original Model 8177 manual dates from 2002), and many of them are now 15 to 25 years old.

Here’s the reassuring part. The master clock driving those displays, usually a Spectracom NetClock or SecureSync, is normally in good shape, and replacing the displays is a well-understood project. (Spectracom is now part of Safran; we covered that transition last year.) It’s still worth checking where your master sits in its own lifecycle; more on that below.

This guide covers a quick check to rule out a simple fault, your realistic replacement options, what each one changes on site, and how to plan the switch without surprises.

First, a quick check: is it the clock or the signal?

Flashing seconds on a TimeView usually mean the display isn’t receiving valid time, not that the display itself has failed. Before replacing anything, check four things:

  1. The master clock is in sync. Its front panel or web interface should show it locked to its reference. On a NetClock 9483, a TV400W won’t synchronize at all until the master is locked.
  2. The RS-485 output is still set to Spectracom Format 0 or Format 1. Any other format and the seconds keep flashing.
  3. Polarity and termination are right. +Data to +Data, −Data to −Data, ground to ground, and a 120-ohm terminator on the last clock in the chain only.
  4. The clock’s plug-in power supply still delivers its rated 12 volts DC under load. Power supplies age too.

One more: a clock that is off by exactly a whole number of hours is showing UTC or the wrong time zone. That’s a setting on the master, not a failure.

Safran’s RS-485 TimeView troubleshooting note walks through each step. If one of these fixes your clock, good: you’ve bought time to plan the rest.

The good news: your master clock can stay

Every option in this guide keeps your existing master clock as the time source. Later NetClock models, such as the 9400 series, and SecureSync units are also network time servers: they serve time over NTP (Network Time Protocol, the standard way devices set their clocks across a network) while still driving the RS-485 serial output that feeds your TimeViews. That means one master clock can feed new network clocks and your remaining TimeViews at the same time, which is what makes a phased replacement possible.

Two caveats are worth knowing up front.

The earliest masters, such as the NetClock/2 (8182), NetClock/GPS (8183) and NetClock/GTP (8183A), predate built-in network time. The 8183A, for example, has no Ethernet port of its own; network time came from a separate add-on unit. If one of these is in your rack, bring the master into the conversation from the start.

The master also has a lifecycle of its own. Safran plans to end-of-life the NetClock 9483 and the SecureSync 1200 series in 2028, as we covered in our end-of-life reminder. That’s not a reason to rush, but if you’re replacing displays in the next year or two, plan the master alongside them. Network clocks will work with its successor, because they take NTP from any standards-based time server. If you want remaining TimeViews to ride through a master upgrade, confirm that the new master’s RS-485 output supports Spectracom Format 0 or 1.

Your TimeView 400 replacement paths

There is no current like-for-like TimeView 400 alternative that drops onto your existing RS-485 chain and speaks its Spectracom format. Safran’s current display range is network-based, and other manufacturers’ wired serial clocks use their own protocols and wiring, so they aren’t a drop-in either. That leaves two realistic ways to get time from your master clock to the wall. Both change something on site, and the next section covers what.

Network clocks: NTP over Power over Ethernet

This is the most common modern path. Each clock plugs into a network switch with a single Cat5e or Cat6 cable that carries both power and time. Power over Ethernet (PoE, the IEEE 802.3af standard) means no outlet is needed at the clock, and the clock takes its time over NTP from the NetClock or SecureSync you already own.

What you gain:

  • No plug-in power supply at each clock.
  • Time zone and daylight saving time set once, not clock by clock.
  • Clocks configured and checked centrally, usually from a browser.
  • No daisy chain, so one cable fault affects one clock instead of every clock beyond it.

Sapling’s SBP 3000 series comes with 2.5-inch or 4-inch digits in 4-digit or 6-digit models, with a built-in web interface and automatic daylight saving time. Bodet’s Style range includes NTP/PoE models such as the Style 7, with 7 cm digits, and the Style 7S, which adds seconds. Novanex makes 4-digit and 6-digit PoE clocks, and Safran’s own current displays also synchronize over NTP and PoE. Analog clocks use the same sync methods if a room calls for them. (More on the general case in the advantages of IP and PoE clocks.)

Wireless clocks

For buildings where pulling new cable is hard or expensive, such as heritage buildings, large campuses, or long runs between buildings, wireless is the alternative. A wireless master or transmitter takes time from your existing time server over NTP and broadcasts it to the clocks. Sapling’s system, for example, uses licence-free 900 MHz frequency-hopping radio in a mesh, where each clock also repeats the signal to its neighbours.

Be clear-eyed about two things. Wireless adds a layer: the transmitter is one more device to power, place and maintain. And the clocks still need power, either batteries or a nearby outlet depending on the model. Some clocks join your existing Wi-Fi instead, which removes the transmitter but brings IT back into the project.

What’s different, and how to plan for it

Your TimeView system was simple: one cable from the master through a chain of clocks, a plug-in power supply at each clock, and the time zone set centrally or with switches. Every replacement path changes at least one of those things. None of them is a problem if you plan for it.

Diagram comparing a TimeView RS-485 daisy chain, with a power supply at each clock, to NTP clocks powered from a PoE network switch, both fed by the same master clock.

Cabling. An RS-485 chain can run up to 4,000 feet. An Ethernet run is generally limited to 100 metres (328 feet) from the switch, and each clock gets its own run instead of sharing a chain. The twisted pair that feeds your TimeViews can’t carry Ethernet, so plan for new Cat5e or Cat6 drops, or a PoE switch closer to where the clocks hang. The existing pathway is often reusable even when the cable isn’t.

Power. Say goodbye to wall-warts. In their place, confirm the switch has enough PoE ports and enough power budget. PoE clocks are modest loads: Sapling rates its SBP 3000 series at 6 to 8.4 watts depending on the model, comfortably within what an 802.3af port supplies.

Who’s involved. Network clocks put your IT team in the project. That usually means a VLAN or port assignment, DHCP or static IP addresses, and allowing NTP (UDP port 123) from the master to the clocks. Bring IT in on day one and it’s a routine request; bring them in the week of installation and it becomes a delay.

Configuration. DIP switches and serial format settings give way to a browser page, or to settings the clocks pick up automatically from the network. Time zone and daylight saving time are set once, which also retires the familiar “the clocks are an hour off after the time change” problem.

What the clock looks like. The TimeView 400 had green digits: 4-inch hours and minutes, and 2.3-inch seconds. Many current models ship with red digits by default, but Sapling, Bodet and Novanex all offer green, so specify it if your room is used to green. If seconds matter, as they do in dispatch, broadcast and control rooms, specify a 6-digit model. Then check digit height against your longest viewing distance. The TimeView 400 was rated for 150 feet (45m); Sapling rates its 4-inch digits at 250 feet (76m), and Bodet rates the Style 7 at 131ft (40m).

Failure behaviour. Everyone in your room knows what flashing TimeView seconds mean. The new clocks will signal “no sync” differently, and the conventions vary by brand. Sapling’s clocks flash the colon when they lose sync. On Bodet’s NTP clocks it works the other way round: after 48 hours without sync, the clock can be set either to go blank or to keep running on its internal time base with the colon no longer flashing. Novanex clocks show dashes and light a service indicator when they can’t reach the time server. Pick the behaviour deliberately and tell your staff what it looks like. Some PoE clocks can also report a lost sync to a monitoring system, so you aren’t relying on someone to spot it.

Phasing and mixed fleets. Phased replacement works because your master keeps driving the remaining TimeViews over RS-485 while the new clocks take NTP. Two things keep it tidy. First, replace room by room, not clock by clock: two digit colours or styles in one room looks odd and invites “which one is right?” questions. Second, when you take a TimeView out of the chain, splice the pair through so the clocks beyond it keep their signal, move the 120-ohm terminator if you’ve removed the last clock, and check whether the clock you’re removing was acting as a repeater for a long run.

Accuracy. For a wall display, NTP from your own master clock is more than accurate enough: far closer to true time than the one second a display can show.

A simple way to choose

Your situationLikely path
A room or building refresh, with network drops available or easy to addNetwork clocks (NTP/PoE)
A few failed clocks, the rest healthyNetwork clocks for the affected room; the rest of the chain stays on RS-485 until its turn
New cable is hard or expensive to pullWireless clocks
Master is a pre-network model, or a NetClock 9483 or SecureSync 1200Review the master at the same time as the displays

If more than one row applies, that’s normal; many sites combine them in phases.

What to have ready before you call

A short look at what’s installed, and where, turns all of this into a straightforward decision. Gather these first and you’ll get a faster, more useful answer:

  1. Master clock model and firmware version (from the front panel or web interface)
  2. Number of TimeView clocks, where they are, and how many have failed
  3. Rough cable routes and lengths, and whether the chain uses a repeater
  4. Whether you need seconds, the date, or a specific digit colour or size
  5. Whether there are network switches with PoE near the clock locations, and who owns them
  6. Whether the clocks show local time or UTC, and any multi-time-zone displays
  7. Any regulatory or operational requirements, such as dispatch or broadcast logging standards

Get a clock replacement check

Telnet’s clock replacement check reviews your master clock, confirms what it can feed, and recommends a path for your displays, room by room if that suits you.

Prefer to start smaller? Send us your master clock model and how many TimeViews you have, and we’ll come back with a quick compatibility check and a replacement recommendation.

Telnet Networks is a Canadian value-added reseller of synchronized time, network visibility, and test and measurement solutions. We work with Safran, Sapling, Bodet and Novanex, and our recommendations depend on the site in front of us. Spectracom, TimeView, NetClock and SecureSync are trademarks of their respective owners and are used here only to identify compatible equipment.

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

Timing Architecture for the AI Campus

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.

LayerFunctionTechnologyPractical target
ReferenceTraceable UTC, multiple independent sourcesGNSS (multi-constellation) at two or more sites, disciplined oscillator, optional external referenceTraceability and diversity, not accuracy
SpineSite-to-site and building-to-building distributionWhite Rabbit over dedicated calibrated fibre, SyncE frequencySub-nanosecond, asymmetry compensated
BuildingLocal grandmaster function per building or hallPTP grandmaster fed by the WR node via 1PPS and 10 MHzLow tens of nanoseconds
FabricDistribution into the compute networkIEEE 1588v2 or G.8275.1, boundary clocks, hardware timestampingTens of nanoseconds node to node
HostLocal clock discipline on GPU, storage and head nodesPTP client with hardware timestamping on the NICTens to low hundreds of nanoseconds
AssuranceContinuous verification of the whole chainIndependent monitoring, topology view, historical replayProvable, 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

The Hidden Foundation of Network Security: Why Precision Time Matters in a Zero Trust World

Zero Trust Architecture has fundamentally changed how organizations think about network security. Identity must be continuously verified. Every access request is interrogated. Trust is earned moment to moment, not granted by default. It’s a powerful model, but it rests on a foundation that many network architects and SOC teams rarely examine closely enough: time. (If you’re looking for a grounding primer on Zero Trust itself, our practical guide to Zero Trust implementation is a good starting point.)

Precise, synchronized, and trustworthy time underpins nearly every security control that Zero Trust depends on. Without it, logs become unreliable, authentication tokens can be manipulated, and anomaly detection loses its ability to reconstruct the sequence of events. In a ZTNA environment, where the accuracy of continuous verification depends on precise event ordering and time-bounded access grants, clock drift is not merely an operational inconvenience, it’s a security gap.

This post explores how Network Time Protocol (NTP), Precision Time Protocol (PTP), and advanced solutions like White Rabbit-based timing systems enable and strengthen network security and Zero Trust implementations, and why investing in a hardened time infrastructure deserves a place on every security architect’s roadmap.

Why Time Is a Security Primitive

Most security practitioners understand that time matters at an abstract level. Logs need timestamps. Certificates have validity windows. Kerberos tokens expire. But the operational reality of just how much security-critical logic depends on synchronized time is often underappreciated until something goes wrong.

Consider what precise, trustworthy time enables across a modern security stack:

  • Log correlation and SIEM accuracy : When endpoints, firewalls, identity platforms, and network devices have misaligned clocks, even small discrepancies (tens of milliseconds to seconds) make it impossible to accurately reconstruct attack timelines. A security incident that spans multiple systems becomes a jigsaw puzzle without a common temporal reference.
  • Certificate and PKI validation : TLS certificates, code signing, and identity certificates all rely on clock accuracy to determine whether a certificate is valid, expired, or revoked. Clock skew can cause valid certificates to appear expired, or, more dangerously, allow expired certificates to be accepted as valid.
  • Authentication token lifetimes : Kerberos, OAuth, JWT, and SAML tokens are all time-bounded. Drift between the issuing authority and the verifying endpoint creates windows of vulnerability. Excessive skew can lock out legitimate users; insufficient skew checking can allow replayed or extended tokens.
  • Behavioral baselines and anomaly detection : Machine learning-driven NDR and SIEM tools build behavioral models based on temporal patterns of activity. Without a consistent time reference, “working hours” anomalies, connection frequency thresholds, and lateral movement detection all become less reliable.
  • Forensic integrity : During incident response, timestamps in logs, packet captures, and audit trails are submitted as evidence. If timestamps across systems cannot be traced to a common, authoritative time source, the forensic value of the data is diminished and potentially challenged.

In a Zero Trust model, where every transaction must be continuously verified and logged for later audit, each of these functions is load-bearing. The accuracy of your time infrastructure directly affects the integrity of your security posture.

Understanding the Timing Stack: NTP, PTP, and White Rabbit

Not all time synchronization is created equal. The protocol you use, and how it’s deployed, determines the accuracy, security properties, and attack surface of your time infrastructure. For a deeper technical foundation, our complete guide to network time synchronization covers the full landscape.

Network Time Protocol (NTP)

NTP has been the workhorse of network time synchronization for decades. It provides millisecond-level accuracy across IP networks and is supported by virtually every device on the planet. For many security use cases like log correlation, certificate validation, and authentication token management, NTP is entirely sufficient, provided it’s properly secured.

The challenge is that traditional NTP deployments are often not. NTP was not designed with security in mind. Without NTS (Network Time Security), the modern authenticated extension to NTP, synchronization traffic can be subject to:

  • On-path manipulation: An attacker positioned between a client and an NTP server can alter timestamps in transit, shifting a device’s clock forward or backward.
  • Replay attacks: Recorded NTP responses can be replayed to steer a target’s clock without active interception.
  • Denial of service: Flooding or disrupting NTP servers can cause clients to drift, degrading authentication and log accuracy across the network.

For SOC teams and security architects, the key takeaway is this: if your environment is running unauthenticated, internet-sourced NTP without monitoring, your time infrastructure is an unaudited trust surface. In a Zero Trust context, that’s an inconsistency worth closing. Our cybersecurity checklist for secure timing outlines the core security features every time server deployment should include.

Precision Time Protocol (PTP / IEEE 1588)

Where NTP operates at millisecond precision, PTP (IEEE 1588) achieves sub-microsecond accuracy, and in hardware-assisted deployments, sub-nanosecond performance. PTP uses a combination of timestamping at the hardware level and a master-slave hierarchy (now referred to as grandmaster-boundary clock architecture in IEEE 1588-2019) to distribute highly accurate time across a network.

From a security standpoint, PTP offers meaningful advantages over NTP:

  • Hardware timestamping eliminates software-layer jitter and makes it significantly harder for attackers to introduce timing manipulation without physical access to network infrastructure.
  • Cryptographic authentication options in PTP profiles allow grandmaster clocks and boundary clocks to sign their synchronization messages, verifying source integrity.
  • Tighter accuracy means better event ordering in high-frequency environments , critical for financial-grade logging, high-speed trading, and industrial control systems, but increasingly important for any organization generating high volumes of security telemetry.

For enterprise and government networks running OT/IT converged environments, 5G infrastructure, or latency-sensitive applications, PTP is the appropriate baseline. It is also increasingly specified in regulatory frameworks that require traceable, tamper-evident timekeeping. Telnet’s precision timing solutions span the full range from NTP grandmasters to hardware-assisted PTP deployments.

White Rabbit: Sub-Nanosecond Precision for Critical Infrastructure

Originally developed at CERN for particle accelerator control systems, White Rabbit (WR) is an open-standard extension of PTP that achieves sub-nanosecond accuracy across fibre-optic networks, synchronizing over 1,000 nodes to within less than 1 nanosecond over links up to 10 kilometres in length.

White Rabbit combines Synchronous Ethernet (SyncE) with precise hardware phase measurements and IEEE 1588 PTP messaging to achieve a level of timing precision that has historically been the domain of laboratory and scientific computing environments. That is changing. As critical infrastructure protection, defence networks, and high-assurance environments increasingly demand verifiable, traceable time with sub-nanosecond integrity, White Rabbit is moving from the research world into operational security infrastructure.

For ZTNA deployments in high-security or critical infrastructure contexts such as telecommunications, power grids, defence, or large financial networks, White Rabbit-based timing provides a hardened, verifiable timing root that supports the most demanding requirements for log integrity, event reconstruction, and forensic accuracy. Learn more about White Rabbit solutions available through Telnet Networks.

Precision Time as a Zero Trust Enabler

The connection between precision time and Zero Trust is not theoretical — it’s structural. ZTNA operates on time-bounded tokens, continuous re-authentication, just-in-time access windows, and behavioral anomaly detection that depends on accurate event ordering. Every one of those controls degrades when clocks drift or diverge.

Clock manipulation is also a legitimate attack vector. An adversary who can skew a target device’s clock, even by a few seconds, can extend the validity of stolen tokens, corrupt the ordering of forensic logs, or cause authentication failures that mask lateral movement. In an environment built around “assume breach,” leaving time as an unverified trust input is a design inconsistency.

A well-designed time infrastructure doesn’t replace the other pillars of Zero Trust; It makes each of them more accurate and harder to subvert.

Building a Hardened Time Infrastructure

Implementing precision time as part of a security strategy involves more than pointing devices at a public NTP pool. A hardened time infrastructure for a security-conscious environment typically includes:

  • Authenticated time sources: Deploying NTS-secured NTP or cryptographically authenticated PTP to ensure time signals cannot be forged or manipulated in transit.
  • Redundant, diverse time references: Relying on a single GNSS source creates a single point of failure. Hardware-based grandmaster clocks with multiple reference inputs (GNSS, OCXO holdover, PTP upstream) provide resilience against spoofing, jamming, and outage. Interference Detection and Mitigation (IDM) capabilities add another layer of protection for GNSS-dependent timing infrastructure.
  • Network-internal distribution: Minimizing dependence on external NTP servers by deploying boundary clocks and internal PTP grandmasters reduces exposure to external attack surfaces.
  • Time monitoring and alerting: Just as you monitor network traffic for anomalies, monitoring clock health across critical nodes,  detecting drift, jitter, or unexplained offsets should be part of SOC operations.
  • Traceability to authoritative UTC sources: For regulated environments, demonstrating that timestamps are traceable to UTC through an auditable chain of custody is increasingly a compliance requirement.

Safran’s timing portfolio, including their SecureSync platform and White Rabbit solutions, represents the high-assurance end of this spectrum, delivering GNSS-disciplined, highly redundant grandmaster clocks capable of maintaining sub-microsecond accuracy even during GNSS outage through precision oscillator holdover. Their White Rabbit implementations bring this level of accuracy directly into critical network infrastructure.

Timebeat takes a complementary approach, delivering software-defined PTP synchronization that enables accurate, resilient time distribution across hybrid and cloud-connected environments. Timebeat’s mesh-based PTP architecture removes traditional single points of failure in timing distribution trees, making high-accuracy time achievable in dynamic, distributed environments where hardware-only solutions face constraints.

Together, solutions like these address the full range of enterprise time infrastructure needs — from the hardened core of a critical facility to the distributed edges of a hybrid cloud environment.

Time Security Is Network Security

Time synchronization rarely gets a line item in a security budget, but in a Zero Trust environment, it should. An unauthenticated, unmonitored NTP deployment is an unaudited trust surface, and that’s an inconsistency that Zero Trust was designed to eliminate.

The right answer isn’t always a full PTP overhaul. For many organizations, the first step is simply authenticating existing NTP with NTS, monitoring for clock drift as part of SOC operations, and ensuring time sources are resilient and traceable. From there, the path to hardware-assisted PTP or White Rabbit is well-understood and incremental.

At Telnet Networks, we work with organizations across Canada to assess time infrastructure gaps and align timing solutions with broader network security and Zero Trust strategies. Get in touch to start the conversation.

Ready to assess your time infrastructure’s role in your Zero Trust strategy? Contact the Telnet Networks team to start the conversation.

Precision Timing Applications in Healthcare and Emergency Services

Precision timing is often associated with telecommunications, financial trading, or power grids, but its role in healthcare and emergency services is just as critical. In environments where seconds, milliseconds, or even microseconds can influence outcomes, accurate and resilient time synchronization helps ensure systems operate safely, efficiently, and reliably.

As healthcare networks become more digital and emergency response systems more interconnected, precision timing is moving from a behind-the-scenes technical requirement to a foundational capability.

Why Timing Matters in Healthcare and Emergency Services

Modern healthcare and emergency operations rely on networked systems, including medical devices, clinical platforms, imaging, communications, and dispatch centers. Precise timing ensures these systems correlate events, maintain data integrity, and support real-time decisions. Inaccurate time can cause data mismatches, delayed responses, compliance issues, and risks to patient and public safety.

Timing architectures must resist disruptions such as GNSS interference, network congestion, or equipment failures. Redundant sources, diverse inputs, and high-stability holdover oscillators maintain accuracy when primary references fail. Continuous monitoring and performance validation allow rapid detection of timing issues and timely correction, keeping healthcare and emergency systems synchronized and operational.

Key Healthcare Applications of Precision Time Solutions

Medical Device Synchronization
– Relies on precision timing to ensure patient monitors, infusion pumps, ventilators, and diagnostic devices operate on a shared time reference
– Enables accurate correlation of vital signs, alarms, and clinical interventions across multiple systems
– Provides the temporal accuracy needed for confident decision-making and reliable event analysis in critical care environments

Electronic Health Records and Clinical Systems
– Maintains correct sequencing of clinical events across hospital and healthcare networks
– Supports continuity of care, accurate documentation, and medico-legal requirements
– Enables reliable analytics for performance measurement, trend analysis, and outcome improvement

Medical Imaging and Diagnostics
– Coordinates data acquisition and processing for MRI, CT, and PET systems
– Improves image accuracy while reducing artifacts
– Supports alignment and secure sharing of diagnostic data across multi-site healthcare networks

Emergency Services Applications of Precision Time Solutions

Emergency Dispatch and Response Coordination
– Provides precise timestamps for call receipt, resource assignment, and response tracking
– Improves situational awareness, performance measurement, and compliance with service-level requirements
– Enables accurate event correlation across police, fire, and emergency medical services

Public Safety Communications
– Supports reliable operation of LTE and 5G-based public safety networks
– Enables accurate handovers, location services, and prioritized communications during major incidents
– Maintains service availability through resilient timing architectures when primary sources are disrupted

Incident Reconstruction and Accountability
– Creates accurate timelines for post-incident investigation, reporting, and training
– Allows confident reconstruction of events across systems and agencies
– Supports continuous improvement and accountability to regulators and the public

Precision Timing Options

Accurate and reliable timing is critical for healthcare and emergency services, where every second can impact patient care and operational efficiency. Organizations need solutions that provide continuous, traceable, and resilient time across a variety of devices and systems. Telnet Networks delivers accurate and reliable timing for healthcare and emergency services through a portfolio of precision timing platforms and expert solution development and design services designed to keep complex networks fully aligned and operational. Enabling client organizations to provide continuous, traceable, and resilient time across a variety of devices and systems.

Safran SecureSync 2400

securesync gps time servers

As the preferred masterclock/time server solution in NENA compliant environments, the Safran SecureSync 2400 is a  Stratum-1 time server with multi-constellation GNSS support and hardware-assisted PTP and NTP services for precise time and frequency distribution. Its military-grade hardware supports redundant power supplies, multiple timing input and output formats, and high-stability oscillators for extended holdover. Advanced monitoring, alarm reporting, and security features enable continuous validation of timing performance, even during GNSS loss or interference.

Bodet Netsilon Master Clocks

Bodet Netsilon provides a cost effective option for environments that require reliable time synchronization without many of the bells and whistles. Bodet Netsilon servers provide a number of output and oscillator options to fit the needs of a variety of deployment scenarios as NTP or PTP  master clock. To ensure your healthcare or emergency service operations stay precisely synchronized and fully resilient, explore the right timing solution for your needs. Contact our sales team to discuss how Safran, Bodet, and our other precision timing solutions can keep your systems aligned and operating at their best.

Mission-Critical Timing: The Transition from Spectracom to Safran

When it comes to critical operations whether in defense, public safety, telecommunications, or infrastructure, accurate, reliable time synchronization is non-negotiable. Over the decades, one name has stood out as a leader in this space: Spectracom.

Founded in 1972 with a focus on delivering secure and resilient timekeeping systems, Spectracom was bought by Orolia in 2007, operated as “Spectracom, an Orolia company” for over a decade, and eventually had its name folded fully into Orolia’s global brand, expanding its reach and capabilities across global markets. Known for innovation in precise positioning, navigation, and timing (PNT), Orolia became a trusted provider of solutions that help keep vital systems in sync, even in the most challenging environments.

The Spectracom NetClock 9300 and 9400 Series served as reliable GPS-based network time servers designed to deliver accurate, traceable time synchronization across critical systems. They were  widely used in public safety, military, broadcasting, and infrastructure environments where precise timing was essential. Supporting both Network Time Protocol (NTP) and Precision Time Protocol (PTP/IEEE 1588), the 9400 Series helped organizations meet compliance standards such as CJIS and NENA, while ensuring seamless communication and event coordination.

Known for its resilience and security, the 9483 Netclock featured multiple time input options including GNSS, IRIG, and external NTP to maintain accurate synchronization even in GPS-denied environments. It also offered secure management interfaces, hardware-level protections, and detailed system logging to support cybersecurity best practices. While the 9483 has been a trusted solution for decades, it officially entered End of Life (EOL), with support ending in 2028, marking the end of its lifecycle as users begin transitioning to next-generation timing solutions.

This journey took a major step forward when Safran, a global leader in aerospace and defense technologies, acquired Orolia in 2022 bringing together unmatched expertise in PNT and mission-critical solutions.

The SecureSync 1200 Series was introduced in 2009 as a compact, flexible network time server designed for environments that required precise, secure, and reliable time synchronization. Built on Orolia’s trusted timing technology, the 1200 Series offered modular configuration options, allowing users to tailor the system to specific needs whether for GNSS-based timing, IRIG, or additional network ports.

Its robust design and cybersecurity features made it a dependable solution for defense, telecommunications, and critical infrastructure, where accurate timekeeping supports both operational integrity and regulatory compliance. The SecureSync 1200 is now at end of sale, with end-of-life scheduled for the end of 2028.

securesync gps time servers

Building on the strengths of its predecessor, the SecureSync 2400 represents the next generation in high-performance time and frequency distribution. Designed under Safran’s leadership, the 2400 offers enhanced scalability, greater processing power, and improved resiliency.

It supports a wide range of timing protocols—including NTP, PTP, IRIG, 1PPS, and GNSS and includes features such as redundant power supplies, increased port density, and improved network security tools. Ideal for mission-critical applications, the 2400 is engineered to operate in complex, modern network environments where precision timing is not only expected but essential.

If you are looking to upgrade your Spectracom 9483 Netclock or SecureSync 1200 and want to discuss your options and what is the best option for you, contact our sales team today for a free consultation and quote.

Welcoming Bodet to the Telnet Networks Partner Ecosystem

bodet telnet partnership

We’re thrilled to announce a new partnership that brings precision, reliability, and European craftsmanship to our time synchronization solutions. Telnet Networks is now an official Canadian partner of Bodet Time, a French manufacturer with over 150 years of expertise in timekeeping innovation. This collaboration enhances our ability to deliver robust, scalable time systems to critical infrastructure sectors across Canada.

A Legacy of Timekeeping Excellence

Bodet’s journey began in 1868 with the crafting of tower clocks. Today, the company is a European leader in time display and synchronization, with all products designed and manufactured in Trémentines, France. Their commitment to quality is evident in their ISO 9001 and ISO 14001 certifications. Even more than 150 years later, they still produce high quality tower clocks.

Comprehensive Clock Solutions

Bodet offers a comprehensive range of digital and analog clocks designed to meet diverse organizational needs, combining precision, durability, indoor or outdoor uses, and aesthetic appeal.

Profil Series – Versatile Analogue Clocks

The Profil Series encompasses the 900 and 700 lines, offering analog clocks suitable for both indoor and outdoor environments. The Profil 900 Series provides three sizes (278mm, 377mm, and 570mm) with options for DIN, notches, or figures on the dial. Available in white, black, or aluminium, these clocks support synchronization via NTP (Ethernet/Wi-Fi) and wired AFNOR or impulse modes, with power options including batteries, 120V/220V, low voltage, or Power over Ethernet (PoE).

The Profil 700 Series expands on this versatility with five sizes (300mm to 800mm) and similar customization options. Designed for robustness, these clocks are ideal for industrial settings, offering recessed and security mounting options for specialized environments.

Style LED Series – High-Visibility Digital Clocks

Bodet’s Style LED Series features 12 models with slim designs and anti-glare screens, ensuring readability in various settings. Digit heights range from 5 cm to 10 cm, and LED colors include red, white, yellow, blue, and green. These clocks support built-in timer functions (with the Style Keyboard accessory) and synchronization via NTP (Ethernet/Wi-Fi), wired AFNOR and impulse modes. Power options encompass 120V/220V, low voltage, or PoE.

For outdoor applications, Bodet offers high-brightness LED clocks with automatic brightness adjustment, digit heights up to 45 cm, and IP54 and IK07-rated aluminium casings. These clocks are designed to withstand environmental challenges, featuring tropicalized electronic boards to prevent oxidation, moisture, and mould.

Cristalys and Opalys LCD Series – Informative and Elegant Displays

The Cristalys LCD Series provides reflective displays with wide viewing angles and high contrast, suitable for indoor environments like offices and hospitals. Models offer various combinations of time, date, temperature, and additional information, with power options including battery (3-year life), low voltage, or PoE.

The Opalys Series enhances visibility with blue backlit LCD displays, maintaining the same informational features as the Cristalys line. These clocks are ideal for settings requiring clear time displays in varying lighting conditions, offering power options of 240V or PoE and an eco mode with programmable schedules.

Each Bodet clock series is designed to integrate seamlessly with synchronized time systems, ensuring accurate and consistent time displays across all areas of an organization.

Advanced Time Synchronization Systems

Bodet offers a comprehensive suite of master clocks and time servers designed to ensure precise time synchronization across various sectors. These solutions cater to the needs of industries ranging from education and healthcare to finance and transportation.

The Netsilon Series

Bodet’s Netsilon time servers provide high-precision time synchronization for IT networks, supporting protocols like NTP and PTP. They are designed to meet the demands of various industries, from manufacturing to finance with varying requirements for precision, customization and resilience.

  • Netsilon 7:Ideal for synchronizing equipment such as access control systems, IT equipment, and video surveillance. It features a TCXO internal oscillator and supports over 2,000 NTP requests per second

  • Netsilon 9:Designed for precise synchronization of equipment like robots and control units. It boasts an OCXO internal oscillator, achieving microsecond-level accuracy, and supports a modular design with various input/output options

  • Netsilon 11:Tailored for applications requiring highly accurate and stable synchronization, such as financial trading systems. Netsilon 11 offers the same high-precision capabilities as the Netsilon 9, with enhanced stability and holdover performance These time servers can be managed remotely via a secure web interface, allowing for easy configuration and monitoring without the need for additional software

 

The Sigma Series

Bodet’s Sigma Series master clocks are engineered to synchronize a network of analogue and digital clocks, ensuring uniform time display across facilitiesThese devices can also control auxiliary systems like bells, lighting, and HVAC systems

  • Sigma P: Offers three programming circuits, enabling control over wired clock systems, relays, or sounders

  • Sigma C: A modular master clock equipped with programming circuits and NTP client/server capabilities for synchronization over Ethernet networks. It also controls sounders and NTP clock systems

  • Sigma MOD:A modular master clock that combines programming circuits with NTP client/server functions. It allows control over slave NTP clock systems, relays, and bell sounders These master clocks support synchronization via GPS, GLONASS, or Galileo antennas and can be configured using Bodet’s intuitive SIGMA software

Beyond traditional clock systems and time servers, Bodet offers a comprehensive range of tower, pool, and scoreboard clocks that demonstrate their commitment to delivering precise and reliable timekeeping solutions across various environments and applications.

Trusted by Global Institutions

Bodet’s solutions are employed by prestigious organizations worldwide:

  • Amazon France: Utilizes Bodet systems for efficient time management in logistics hubs
  • Roissy Charles de Gaulle Airport: Relies on Bodet for synchronized time displays across terminals
  • University Hospital of Montpellier: Ensures precise timekeeping for critical healthcare operations
  • Royal Mail and Barclays Bank: Implement Bodet’s time solutions for operational efficiency

Bringing Bodet to Canada

As Bodet’s Canadian partner, Telnet Networks is excited to offer these state-of-the-art time synchronization solutions to our clients. Whether you’re in healthcare, education, transportation, manufacturing, technology or any sector where precise timekeeping is crucial, we’re here to provide tailored solutions that meet your needs.​

Contact Telnet Networks today to learn more about Bodet’s offerings and how we can assist in implementing a solution that ensures accuracy, reliability, and efficiency across your operations.

NTP vs. SNTP: What’s the Difference?

Network Instruments Accurate Monitoring


NTP vs SNTP - What's the difference?

By David Sohn, Solution Architect

(And Which One Do You Really Need?)

NTP (Network Time Protocol) and SNTP (Simple Network Time Protocol) are similar TCP/IP protocols in that they use the same time packet from a Time Server message to compute accurate time. The procedure used by the Time Server to assemble and send out a time stamp is exactly the same whether NTP (i.e., full implementation NTP) is used, or SNTP is used.

The difference between NTP and SNTP is important in the time synchronization program running on the client side on each system.

The time synchronization program, whether it is a Windows built-in program like W32Time (which uses the SNTP protocol) or a third-party add-on, determines which protocol is being used — not the time server. The time server does not care. The difference between NTP and SNTP is in the error checking and the algorithm for the actual correction to the time itself.

The NTP algorithm is much more complicated than the SNTP algorithm. NTP normally uses multiple time servers to verify the time and then controls the slew rate of the system. The algorithm determines if the values are accurate using several methods, including fudge factors and identifying time servers that don’t agree with the other time servers. It then speeds up or slows down the system clock’s drift rate so that (1) the system’s time is always correct and (2) there won’t be any subsequent time jumps after the initial correction.

Unlike NTP, SNTP usually uses just one time server to calculate the time, then “jumps” the system time to the calculated time. It can, however, have back-up time servers in case one is not available. During each interval, it determines whether the time is off enough to make a correction and if it is, applies the correction.

Clear as Mud?

If this is not completely clear, consider an analogy of comparing and adjusting a wristwatch to a clock on the wall. The wristwatch is analogous to the “client” device (like a PC) and the clock on the wall is the time server. With SNTP, you always look at the clock at pre-determined intervals. Let’s say one per hour. (As an aside, the act at comparing time for computer synchronization is known as a “poll.”)

When you think it is 12:00:00 you look at (poll) the clock to see that it is 11:59:57. You are three seconds fast, so you set your watch back three seconds. You do not do anything else until 1:00:00. You look again at the clock to see that it is 12:59:57 – again, three seconds fast — and again you set your watch back three seconds. Every hour, you reset your watch 3 seconds to be in sync with the clock on the wall.

From an error perspective, you are most accurate immediately after the poll and you progressively get worse. The maximum error happens immediately before the poll, when a sudden adjustment occurs, such as when time goes from 12:59:57 to 12:59:58 to 12:59.59 to 1:00:00 to 12:59:57.

If a maximum error of three seconds and the discontinuity of the time scale bothers you, consider the NTP case. Here, you want to react knowing that your watch is gaining three seconds every hour, so you don’t have to change it so often.

Simply compensate for the drift by using your error vs. time measurements. You do not need to use the same measurement period all the time. All you need to know is the rate and direction of the change.

After you have a pretty good feel for the drift, you can program your watch to adjust in real time. You want to make very small adjustments, so that at any given time you are in sync with the clock on the wall, without even looking at it.

Of course, the drift rate may change over time, so you do want to continually poll the clock, and apply the best correction you can come up with. And with that you get a wristwatch that is seemingly never out of synchronization!

Which One Do You Need?

It all depends on your application, but in general, SNTP clients should only be used where time synchronization is not critical for your systems. For all other clients, and for systems that will also serve time to other systems, you should utilize full NTP implementations to include reference selection and clock steering algorithms to maintain accuracy through the full timing path.

Looking at the time servers themselves, the selection of a time server that uses SNTP or NTP to serve time only should focus on whether that time server would ever synchronize to NTP as a primary or secondary reference — in which case, only full NTP should be used. To simplify things, SNTP should be used only at the start or end of the network timing path, and only at the end of the network timing path where time synchronization is not critical for your systems.

Customization Nation with Sapling Digital Clocks

No matter the product, everyone has different tastes and styles they prefer. Because of this, people really enjoy the ability to customize the items they purchase to meet these preferences. Giving customers the option to personalize their product or service has benefited many different companies in many different industries.

Let’s take the shoe industry as an example. Nike has been wildly successful with the Nikeid option on their website. This option gives their patron the option to customize any type of shoe they want with any combination of colors. The car industry has also jumped on the customization bandwagon. Almost every major car company has an option on their website for their customers to customize the make, model, color, accessories and so much more.

The Sapling Company understands the importance of customization and as the manufacturer of synchronized time systems; Sapling has an array of options to satisfy the broadest of needs. We offer four different synchronized time system options, including: Wired, Wireless, Talkback, and IP. These systems include a master clock at the center of the network and multiple secondary clocks that display the accurate time. The master clock is updated with the accurate time from NTP of GPA, and then sends a signal to the secondary clocks. More specifically within a wireless clock system, the secondary clocks both receive and transmit the signal, until all of the clocks are properly updated.

Within the four systems is the option of what type of clock you would want: analog or digital. If you chose the round analog clocks, then you would get the option of the 12” or 16”clock. Sapling also offers a 9” or 12” square clock for more variety within the analog family. Both the round and square clocks have the additional options of customizable hands and dials!

If you chose the digital clocks, then you would be hit with the brand new color customization display options. While red is the standard color option, you will now have the choice between green, white, amber and blue.

Thanks to Sapling for the article.