OCXO vs Rubidium Holdover: When Each Oscillator Class Earns Its Place

Why holdover is the only oscillator question that actually matters

When GNSS is healthy and the grandmaster is locked, the local oscillator is irrelevant — the GNSS receiver dominates the time error budget. The oscillator only earns its line item on the procurement spreadsheet during holdover, when GNSS is unavailable and the local oscillator has to run on its own physical properties for some period of time.

This is why specifying an oscillator class without first specifying a holdover requirement is the most common mistake we see in grandmaster RFPs. "Rubidium" sounds impressive but is wasted budget if your GNSS environment never produces an outage longer than 10 minutes. Equally, "OCXO" is dangerously cheap if your network sits in a contested electromagnetic environment where a four-hour GNSS denial is plausible.

Holdover is asymmetric: you only pay for it on bad days, but the cost of being wrong is paid by the entire downstream network at exactly the moment you can least afford it.

The four oscillator classes in production grandmasters

Modern PTP grandmasters ship with one of four oscillator classes. Each has a characteristic Allan-deviation curve, a price point, a power envelope and a use case where it is the correct choice.

OCXO: cheap, sufficient, often correct

Oven-controlled crystal oscillators are the workhorses of the PTP world. A modern OCXO uses a precisely cut quartz crystal in a temperature-controlled oven, holding the crystal at a fixed temperature (typically 70–80°C) so its frequency is stable to a few parts in 10⁹ over short timescales. For a grandmaster sitting in an air-conditioned data centre and disciplined to GNSS most of the time, an OCXO is genuinely sufficient — its drift over 30 minutes of holdover is in the low hundreds of nanoseconds.

OCXO drift is dominated by ageing (slow long-term frequency change) and temperature sensitivity. Both can be characterised and compensated by the disciplining algorithm, which is why a well-disciplined OCXO grandmaster can outperform a poorly disciplined rubidium grandmaster during the first hour of holdover.

The OCXO failure mode is graceful: drift increases monotonically over time, the operator can see it coming via observability metrics, and no surprises. The OCXO failure mode is also predictable: by 24 hours of holdover, you're typically 1–10 microseconds out, which is too much for most regulated environments.

Double-OCXO: the underrated middle ground

Double-OCXO designs use two OCXOs cross-disciplined against each other (often with one running as a primary and one as a quality monitor). The cross-discipline removes a lot of the short-term noise from each individual oscillator, and the redundancy means a single OCXO failure does not immediately degrade the grandmaster.

DOCXO holdover performance sits closer to a low-end rubidium than to a single OCXO — typically 30 nanoseconds over one hour and a few hundred nanoseconds over 24 hours. The cost premium over a single OCXO is real but small compared to the gap to a rubidium grandmaster, and DOCXO uses substantially less power, which matters in high-density rack deployments.

For most finance, broadcast and mid-tier telecom networks, DOCXO is the sweet spot. We rarely see customers regret a DOCXO purchase. We frequently see customers regret either over-specifying to rubidium (and burning the budget on power and cooling) or under-specifying to single OCXO (and being burned by an unexpected GNSS event).

Rubidium: when atomic-grade actually matters

Rubidium atomic clocks use a hyperfine transition in rubidium-87 atoms as a frequency reference. The physics is fundamentally more stable than a quartz crystal, by several orders of magnitude over long time scales. A modern rubidium grandmaster will hold time within 100–500 nanoseconds across 24 hours of holdover, and the drift is approximately linear and predictable.

Rubidium is the correct choice in three scenarios. First, telecom G.8275.1 deployments where ITU-T accuracy classes effectively mandate atomic-grade frequency references. Second, regulated financial timestamping environments where a single multi-hour GNSS event during a trading day has direct regulatory and financial consequences. Third, defence and government networks where holdover requirements explicitly extend to many hours or days, and where the threat model includes deliberate GNSS denial.

Outside those scenarios, rubidium often becomes a vanity purchase. The cost premium is real (5–10× an OCXO at the time of writing), the power and cooling costs are non-trivial, and the rubidium physics package itself has a finite life — typically 8–12 years before frequency drift becomes operationally significant. If you don't actually need rubidium-grade holdover, you're paying for capability you'll never use.

Caesium and White Rabbit: where this stops being a holdover question

Caesium primary references and White Rabbit fibre-distributed timing both exist on the spectrum, but neither is really a "holdover oscillator" in the OCXO/Rubidium sense. Caesium clocks are primary frequency standards used in national metrology labs and the most demanding scientific applications — they're large, expensive, power-hungry, and overkill for almost any commercial deployment.

White Rabbit, by contrast, isn't a holdover technology at all — it's a fibre-distributed timing protocol that delivers sub-nanosecond accuracy continuously, for as long as the fibre link to the upstream reference is up. White Rabbit makes sense in campus networks, accelerator facilities, and anywhere you have controlled fibre between sites and need accuracy beyond what PTP can deliver. It's not in competition with OCXO or rubidium — it's a different layer of the architecture.

How to specify holdover correctly

Three steps: pick your worst-case GNSS unavailability duration, pick your maximum acceptable phase error during that window, and find the cheapest oscillator class that comfortably meets both. "Comfortably" means the published holdover spec at twice the duration, with a margin of two on the phase error — oscillator drift specs are typical-case figures, not worst-case.

If you can't pick a worst-case duration, you have a different problem to solve before you choose an oscillator. Talk to the network operations team about historical GNSS-related incidents, talk to physical security about antenna access, and talk to whoever owns your geographical risk model. The number is in your organisation somewhere — find it before you buy hardware that depends on it.