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.

The Benefits of Using 2-Wire Digital Master Clock System

If you are considering a wired clock system for your facility, the 2-wired Digital Master Clock System option with Sapling may be the best option for you. Take a look at the unique advantages of this system below. In addition to the written description, check out our video at the bottom to see a visual depiction of how the 2-Wire Digital Clock System works.

Power/Data on the Same Line

Most wired clock systems require three or four wires. With Sapling’s 2-Wire Digital Communication System, the converter box supplies the power and amplifies the data, so that power and data are integrated on the same line. Fewer wires mean a cleaner, less cumbersome and more efficient system.

Instant Correction

As with all of Sapling’s clock systems, our goal is to provide synchronized, accurate time to keep your education, healthcare or business facility operating at its best. The 2-Wire Digital Communication System provides time updates to all of the clocks as often as once per second. With such frequent corrections, your clocks are guaranteed to show the accurate time, all the time. Another auto correction feature is the 5 minute synchronization after a power outage. If power is lost, you won’t have to worry about resetting the clocks or waiting a few hours for them to be re-synchronized. Within five minutes of getting power back, the master clock will send a signal to reset all of the clocks to the accurate time. Even if a power outage causes some temporary chaos in other areas, clock malfunctions or time inaccuracies will not be issues to add to the mix. Sapling takes care of that part for you.

Effortless Installation

The installation of the 2-Wired System is simple and straightforward for a few reasons. First, the low voltage requirement means that you do not need a certified electrician to install the system in most countries. Having two wires going from the master clock to each individual clock instead of four also makes setup quicker and easier. Even if a mistake is made with the two wires, our cutting-edge reverse polarity detection technology will recognize the error and autocorrect it. What could be easier than that?

Hopefully, the only thing easier is making the decision to install Sapling’s 2-Wire Digital Master Clock System for its advanced technological capabilities, ease, accuracy and the superior quality and service that you can expect from Sapling.

Thanks to Sapling for the article.

Sapling’s Master Clock – Leader of the Pack – Part 2

In continuing with our post explaining how Sapling’s master clocks can receive time, the second option a user has to receive time is through a GPS Receiver.

Receiving time from a GPS satellite is not only extremely accurate, it is also very secure. With the GPS Receiver, the facility does not have to go outside the facility’s established firewall and use a time source via the Internet.

A GPS receiver is built-in to the master clock and sends out the master clock’s exact location to satellites around the world. From the satellite, the master clock receives the accurate UTC (Coordinated Universal Time), then corrects to the local time based on the user’s location.

The GPS Receiver option can be used in conjunction with the NTP Server option, which you can learn about here. A user has the ability to choose which option will be the main time source and which will be the backup time source. By utilizing both options, a user will have redundancy within their system, ensuring accuracy. Receiving time via GPS is optional with a Sapling’s master clock.

Stay tuned next week for the third way Sapling’s master clocks can receive time! If you are interested in learning more about our master clocks in the meantime, visit our website for more info or check out our YouTube video explaining our master clocks more in depth.

Thanks to Sapling for the article.