How to Choose a PTP Grandmaster Clock: A Practical Buyer's Guide

TL;DR

▸Specify holdover requirement, GNSS environment and PTP profile before anything else — these three drive 80% of the deployment outcome.
▸Insist on hardware timestamping, open-standard reference designs (OCP TAP, linuxptp) and observability hooks. Walk away from anything that hides health metrics behind a vendor portal.
▸Buy two grandmasters minimum. Test failover quarterly in production. The first time you fail over a five-year-old grandmaster pair will surface bugs you have to fix.

Start with three numbers, not a feature comparison

Most PTP grandmaster RFPs start by tabulating features: port count, rack height, GNSS bands, oscillator type, supported profiles. This is the wrong place to start. Before you compare vendors at all, you should be able to write down three numbers that describe what you actually need from the grandmaster.

Holdover budget. How long can your network tolerate the grandmaster running without GNSS, and what is the maximum acceptable time error during that window? "Four hours, drift below one microsecond" is a useful answer. "As long as possible, as accurate as possible" is not.

Distribution accuracy budget. How much time error can your downstream slave clocks accept? Trading systems with MiFID II reporting often require sub-100 nanoseconds. Broadcast ST 2110 needs about one microsecond. 5G fronthaul allows up to ±1.5 microseconds end-to-end. Your downstream tolerance sets the precision bar your grandmaster has to clear.

Failure tolerance. How long can your network operate with zero healthy grandmasters before it materially impacts the business? Minutes? Hours? This sets your redundancy strategy and your geographical distribution.

Why this matters

These three numbers convert vague "we need timing" requirements into concrete specifications you can hand to vendors. They also let you reject vendors confidently — if the answer to your holdover question is "oh, our datasheet doesn't quite cover that scenario," you have your answer.

The five-question vendor screen

Once you know what you need, the vendor conversation gets short. Here are the five questions we ask of any grandmaster being considered for a TimeBeat customer deployment, in priority order. Vendors that can't answer them confidently are eliminated.

●Show me your BMCA implementation. "Best Master Clock Algorithm" handles failover between redundant grandmasters. Bugs here are common and only surface during real failures. A serious vendor can show you the source code, the test plan, or both.
●What's your GNSS receiver lineage? Multi-band, multi-constellation, anti-jam, anti-spoof. If the receiver is single-band L1 GPS only, the grandmaster is not suitable for any 2026 production deployment.
●Which PTP profiles ship with correct defaults? G.8275.1, G.8275.2, ST 2110, default. "Supported" is not the same as "shipped with the right defaults." Ask for the configuration file.
●Is the firmware auditable? Open source (linuxptp, OCP TAP) is the gold standard. Proprietary firmware with a published change log is the minimum acceptable. Closed binary blobs with no audit trail are disqualifying.
●How does it expose health telemetry? Prometheus, gNMI, syslog, SNMP — you need machine-readable metrics flowing into your monitoring stack. "It has a web GUI" is not an answer.

What to ignore in the datasheet

Grandmaster datasheets are dense and most of the density is decorative. The following properties are real but rarely decision-driving for a production deployment.

Maximum port count. Unless you're consolidating boundary clocks into the grandmaster itself, two ports are enough. Three or four is luxury. Twelve is marketing.

Rack U height. Almost every modern grandmaster fits in 1U or less. The 1U vs 2U debate is irrelevant unless your rack is genuinely full, in which case you have a different problem.

Maximum messages per second. Theoretical PTP throughput is rarely the bottleneck. The bottleneck is BMCA correctness during failover and GNSS receiver behaviour during degradation, neither of which appears on the front page of a datasheet.

Time-to-first-fix. Cold-start GNSS lock time of 60 seconds vs 90 seconds doesn't matter unless you're rebooting grandmasters routinely, which you should not be doing.

The three things you can't get back if you skip them

Some procurement decisions are reversible — if you buy the wrong number of ports, you can buy more. Some are not. Three properties of a grandmaster purchase, if you get them wrong, force you to rip-and-replace later. Get these right at procurement time.

Open vs closed firmware. Once you've committed to a closed-firmware vendor, you've committed to their support model, their bug-fix cadence and their pricing. The cost to switch is multiplied by the number of grandmasters you've already deployed.

Oscillator class. You cannot upgrade an OCXO to a rubidium in the field. If your holdover requirement is going to grow over the deployment lifetime — and in regulated industries, requirements rarely shrink — buy the better oscillator now.

Observability surface. A grandmaster that doesn't expose machine-readable health metrics will never be properly observable, regardless of how much you spend on the monitoring stack. The integration point has to exist on the device.

Frequently asked questions

How much should a PTP grandmaster cost?+

Entry-level OCXO-based grandmasters from open-hardware vendors start around $4,000–$8,000 per unit. Rubidium-based telecom-grade grandmasters typically run $15,000–$40,000. White Rabbit nodes for sub-nanosecond fibre timing are $25,000+ per port. Caesium primary references for metrology applications are $100,000+. Software, support and observability platforms add to this, but for most production deployments hardware is the dominant line item.

Do I need a hardware grandmaster, or can I use software PTP on a server?+

For most production deployments, you need a hardware grandmaster. Software PTP running on a general-purpose Linux server without hardware timestamping suffers from interrupt latency, kernel scheduling jitter and NIC driver variation that introduce hundreds of microseconds of error — enough to swamp the precision benefits of PTP entirely. The exception is software PTP on servers with hardware-timestamping NICs (Intel E810, NVIDIA ConnectX-6 and later), which can be production-grade but requires careful tuning.

How do I test a PTP grandmaster before buying?+

Ask the vendor for a 30-day evaluation unit. Set it up alongside your existing reference, capture phase offset measurements over a representative time window (at least seven days, ideally including a weekend), and force at least one GNSS outage to characterise holdover. Test BMCA failover by powering off the active grandmaster while monitoring downstream slave clocks. Any vendor who refuses an evaluation is telling you something.

How long does a PTP grandmaster last?+

Hardware lifetime is typically 7–10 years for the chassis and 5–7 years for OCXO/Rubidium oscillators. Firmware support life is the more important question — proprietary vendors often deprecate older models within 4–5 years, forcing rip-and-replace. Open-hardware grandmasters running linuxptp can be supported indefinitely by the operator.

Related guides

Pillar guide · PTP

PTP Grandmaster Clock: The Complete 2026 Guide

What a PTP grandmaster clock actually does, how to choose one, and what separates a grandmaster you can trust from one that quietly drifts. Written by TimeBeat's engineering team for network architects deploying IEEE 1588 in production.

Cluster · Holdover

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

Choosing between OCXO, double-OCXO and rubidium holdover oscillators in a PTP grandmaster — the drift numbers that matter, the deployment scenarios where each is correct, and the trade-offs nobody talks about.

Cluster · PTP profiles

PTP Profile Selection: G.8275.1, G.8275.2, ST 2110 and the Default Profile

Choosing the right PTP profile is the difference between a deployment that works on day one and one that needs three weeks of debugging. A practical guide to G.8275.1, G.8275.2, ST 2110 and the IEEE 1588 default profile — what each is for, what defaults matter, and how to mix them.