Questions to ask a clock vendor
You are buying a clock for a datacenter. You are not going to build a lab and measure it yourself, and you should not have to. What you need is a short list of questions whose answers tell you whether the person selling it understands what they are selling.
These are ordered roughly by how much they reveal per second spent asking.
One question comes before all nine, and it is for you rather than the vendor: why do you want precise time? Timing requirements usually arrive from outside engineering as a bare number, and whether that number is really about sequencing, elapsed time, or a defensible record changes which of the answers below you should care about.
The nine below assume you are buying a finished GPS network clock — a box that hands you NTP and PTP and has already made every internal engineering decision on your behalf. That is the common case and these are the questions that expose whether it was made well.
If you are buying a module or a geodetic receiver to build a clock around, the vendor conversation is a different one: you are shopping for exposed capabilities rather than for delivered performance, and most of what matters is in the integration manual rather than in anything a salesperson will tell you.
1. “Accurate to 15 ns” — accurate in which sense?
Accuracy is two things combined: trueness and precision. A box that is reliably 15 ns late and a box that scatters ±15 ns around the right answer both get described as “accurate to 15 ns”, and they behave completely differently in your estate. Ask which.
2. Against what reference?
“Accurate to UTC” needs a follow-up, because UTC is not available in real time. In practice the answer is a GNSS-derived estimate, or a lab’s UTC(k), or the vendor’s own house standard. Those are not equivalent claims, and a vendor who does not distinguish them has not thought about it.
3. Is a number in a specification a min, a max, a typical, or a measured distribution?
A number given as a min or a max is a promise about the worst unit off the production line. A “typical” number is a story about a good one. A distribution is evidence. Ask which you are being shown, and how many production units it came from.
4. Over what averaging interval?
Stability is a curve, not a number — it depends on how long you watch. A single figure with no interval attached is either shorthand for a curve the vendor has, or a sign that they do not have one.
Ideally you want a TDEV(τ) plot, because it directly shows time stability as the averaging interval changes. Its vertical axis is in units of time — likely nanoseconds — which is the same currency as your error budget.
Failing that, MDEV(τ) converts exactly: TDEV(τ) = τ·MDEV(τ)/√3. MDEV itself is dimensionless like ADEV; the τ in that formula is what supplies the units. So a modified-Allan-deviation plot is the same information wearing a different hat.
ADEV is the one usually published and the one that does not convert. It shows frequency stability as the averaging interval changes, and its vertical axis is dimensionless — a fractional change in rate. Think very small percentages, then parts per million, then parts per billion, and keep going: the clocks this page is about are quoted at parts per trillion and better.
ADEV and MDEV respond differently to white and flicker phase noise, which is the entire reason MDEV exists, so there is no general formula that takes you from one to the other. An ADEV plot is still worth having and still tells you a great deal — just not TDEV, and a vendor who hands you ADEV while you asked for TDEV should be asked which they measured.
In the absence of any plot, a table of stability as τ changes is acceptable, but it wants at least four or five rows — enough to get a flavor of the shape the plot would have had. One row is not a curve.
5. What is the holdover figure, and against what threshold?
A holdover number is meaningless without two companions: the error threshold it is measured to, and the oscillator it assumes. “Twenty-four hours of holdover” answers nothing until you know whether that means 1 µs or 1 ms, and whether it is the OCXO or the rubidium option.
The long form of this question, including why the answer usually turns on the temperature of your room rather than the crystal, is how GNSS holdover works
6. What is the resolution of the number you are quoting me?
Resolution bounds what can be seen, not what is true. Worse, resolution coarser than the real scatter conceals the scatter — an instrument that reports the same value every time may be perfectly repeatable or may simply be unable to see its own noise. Ask, and ask how they know which it is.
7. Does that figure include the antenna feedline?
Usually it does not: the number was measured at a connector, and your cable is in the uncompensated path. Ask whether the vendor compensates feedline delay, whether they expect you to configure it, and what happens if you get it wrong. That last answer is often the most revealing thing in the conversation.
8. What is the traceability chain?
Traceability is a documented, unbroken chain of calibrations with uncertainty accounted at each step — not a logo. Ask who calibrated the reference they measured against, and when. If the answer is “we use GPS”, that is a statement about a signal, not a chain.
9. How would I verify any of this myself?
The best question, kept for last, because the answer is almost never technical. A vendor confident in their numbers will tell you what to measure and what you should expect to see. One who is not will explain why you cannot.
If you want to take them up on it, that is a different set of questions.
And once the box is bought and racked, the questions stop being about the vendor and start being about you: datacenter GNSS time best practices is the operating checklist, and only one of its eight items is a purchase decision.