NTP dependency tree: who follows whom, and on which clock

By Richard DEMONGEOT · Campaign of 2026-08-07 · Measured reconstruction, from six autonomous networks · Data CC BY 4.0

Every NTP server publishes, in each of its replies, a four-byte field called refid. A stratum 1 puts the name of its clock in it; a stratum 2 or above puts the address of the upstream it follows. This is the only public way to reconstruct who depends on whom — and therefore to see whether a country's advertised diversity is real, or whether everyone follows the same pendulum.

This page reconstructs a snapshot, not an architecture. It does not say how a server is configured: it says which upstream it was following at the precise instant it answered us. For per-country counts and operator concentration, see the NTP and NTS map.

4039

reachable servers

759

on a local clock

3289

with a visible upstream

dependents of the most followed

These are orders of magnitude: the refid reveals only one upstream per server, and the counts are reconstructed from the database — within one or two units of the published dataset.

This page details only the ten most-followed upstreams, and what it leaves out matters: of 1095 distinct upstreams observed, 55.3% (605) have a single NTP server following them.

In other words: the concentration is not there. The ten largest carry only 13.2% of the 3292 visible dependencies — the rest is a dust of upstreams with one or two followers. Systemic risk, if any, is not read here: it would be read in the clocks, where a handful of labels cover most stratum-1 servers.

The most followed upstreams

This is where a concentration the map does not show can be read: a country may present forty distinct operators, thirty-eight of which follow the same clock. The first on this list concentrates 2.4 % of the visible dependencies.

That percentage is a proportion of ELECTED sources — not of configured sources, and not a market share. The refid does not say what a server is configured with: it says which of its sources it had elected at the instant it answered. A server declaring four shows only one, and this table's denominator counts elections only, one per server.

Everything here is undercounted, on both sides at once. The leading upstream's share understates its real participation over time: it also serves the hours when we did not catch it elected. And the other upstreams' shares understate theirs even more: those not elected at that instant do not appear at all. No figure on this page can be read as a maximum.

If the leading upstream went down, its followers would switch to machines that appear nowhere on this page — and a fallback server may well surface the stratum 1 directly in its refid, changing the shape of the tree without a single new dependency having come into being. A single measurement sees one election; only accumulated campaigns will see the switches and approach the pool of candidates rather than the elected one. “Who follows whom today” is not yet “who can follow whom”, which is the question risk actually asks.

Upstream	stratum	dependents	share	address followed	its clock
ntp.ix.ru	stratum 1 (earlier reading)	80	2.4 %	`194.190.168.1`	no local clock: it follows another server
ptbtime1.ptb.de	stratum 1 (earlier reading)	76	2.3 %	`2001:638:610:be01::108` followed over IPv6, digest broken	no local clock: it follows another server
ntp2.rrze.uni-erlangen.de	stratum 1 (earlier reading)	50	1.5 %	`131.188.3.222`	no local clock: it follows another server
ntp-p1.obspm.fr	stratum 1 (earlier reading)	40	1.2 %	`145.238.80.80`	no local clock: it follows another server
80.72.67.48 refid non résolu	never probed by us	36	1.1 %	`80.72.67.48`	not measured here
anon-70176311	stratum 1 (earlier reading)	36	1.1 %	`82.35.162.146`	no local clock: it follows another server
anon-2a83ae6a	stratum 1 (earlier reading)	31	0.9 %	`82.43.52.28`	no local clock: it follows another server
ntp1.rrze.uni-erlangen.de	stratum 1 (earlier reading)	30	0.9 %	`131.188.3.221`	no local clock: it follows another server
ntp0.rrze.uni-erlangen.de	stratum 1 (earlier reading)	29	0.9 %	`131.188.3.220`	no local clock: it follows another server
ntp1.nl.uu.net	stratum 1 (earlier reading)	28	0.9 %	`193.79.237.14`	no local clock: it follows another server

The 10 most-followed upstreams, out of 1095 distinct ones. They carry 436 of the 3292 visible dependencies. The rest is not a negligible tail: more than half of all upstreams have a single dependant. The full dataset is in the JSON for this campaign.

What is not named here is not unnamed by accident. A server our inventory marks as not published appears under a stable pseudonym and without its address; an upstream discovered solely through a third party's refid is named only if its name carries a service word and a public list already cites it. Otherwise only the address appears — it is what the refid contains, and anyone querying the same server reads it too.

The declared clocks

A stratum 1 follows no one: it puts a four-character label in its refid naming its physical reference. It declares it — nothing in the protocol attests to it, and a misconfigured server will display GPS with the same confidence as one wired to a receiver.

Label	servers	share	what it is	seen at
`PPS`	236	31.7 %	Pulse per second — an electrical signal, carrying no date	—
`GPS`	180	24.2 %	GPS receiver, with or without PPS	—
`GNSS`	38	5.1 %	Multi-constellation receiver (GPS, Galileo, GLONASS, BeiDou)	—
`MRS`	36	4.8 %	Multi-reference source — Meinberg's "Multi Reference Source" range, combining several signals	—
`GPSs`	22	3 %	Label specific to the operator or its hardware — the protocol does not standardise it	—
`PHC0`	21	2.8 %	Label specific to the operator or its hardware — the protocol does not standardise it	—
`MBGh`	20	2.7 %	Meinberg hardware	—
`PPS0`	18	2.4 %	Pulse per second, input 0	—
`NIST`	16	2.2 %	National Institute of Standards and Technology, US metrology institute	—
`SHM`	10	1.3 %	Label specific to the operator or its hardware — the protocol does not standardise it	—
`ATOM`	9	1.2 %	Local atomic clock, or a PPS signal labelled as such	—
`PZF`	9	1.2 %	Meinberg phase-modulated DCF77 receiver	—
`DCF`	8	1.1 %	DCF77, the German longwave transmitter	—
`TMNL`	7	0.9 %	Label specific to the operator or its hardware — the protocol does not standardise it	—
`kPPS`	6	0.8 %	Kernel-timestamped pulse per second, steadier than in user space	—
`NICT`	5	0.7 %	Label specific to the operator or its hardware — the protocol does not standardise it	—

IPv6 upstreams, and how they nearly fooled us

The refid field is four bytes. An IPv6 address is sixteen. When a server follows an IPv6 upstream, RFC 5905 therefore has it publish the first four bytes of the MD5 digest of the address. The result looks like an IPv4 address and is not one.

Our campaign contains some: eight servers appeared to depend on 29.88.99.4, an address of the US Department of Defense that has never served time to anyone. Counting that as a dependency would have manufactured a concentration point that does not exist.

We resolve them, and without brute force. Searching for the address behind a digest would mean sweeping the IPv6 space; computing the digest of the addresses we already know costs one DNS lookup per name. Independent check: chronyc tracking displays the correspondence itself, as Reference ID : ED11CC5F (2001:638:610:be01::108).

The trap was not where we expected it. Nothing forces a digest to land in a reserved range: 84.138.115.198 is a Deutsche Telekom address with a subscriber-line reverse name, and it is the digest of 2001:2035:0:1a34::3 — one of our own servers. As long as the dictionary was consulted only for implausible addresses, those refids passed for real dependencies and manufactured concentration points that did not exist. It is now consulted for every refid, and each resolution is checked against a second, independent witness: a follower sits exactly one step above its upstream.

Not everything unaddressable is a digest. Some servers publish a private address because they genuinely follow an internal upstream — 169.254.169.123 at AWS, 10.219.8.4 at Cloudflare, 192.168.33.131 at LAAS. That is not a riddle to solve, it is intelligence: those operators hold their own reference and publicly depend on no one.

What this tree does not say

This is not a configuration. The refid gives the upstream followed at the instant of the reply. A server configured with four sources shows only one, and will switch at the next reselection. The tree is a lower bound on real dependencies.
A declared clock is not a verified clock. GPS in a refid is the operator's claim, not proof.
An upstream outside our inventory stays unnamed. And that has nothing to do with stratum 2 in particular: we do not measure every stratum 1 in the world either. An upstream we have never probed therefore appears by its address, with no stratum and no clock — which says nothing against it.
Mutual peering will stay out of reach. In a symmetric association (peer, not server), two machines of the same stratum cite each other. We cannot verify that reciprocity from outside: when a digest points at a machine of the SAME stratum, we create no link and record an anomaly. That is an accepted blind spot, not a limit another measurement would lift.
What rests on the digest alone, and how much. 0 links out of 3289 come from a broken digest; of those, 0 are corroborated by the stratum rule and 0 rest on the digest alone. The risk of a four-byte collision is not judged in the abstract but against our own corpus: fooling the first group would take two simultaneous accidents, the second only one.
A pool zone is not a machine. hu.pool.ntp.org returns a random member on each resolution: the stratum we read and the refid we read may come from two different machines. Those names are excluded from the tree — 0 in this campaign — because their dependency cannot be attributed to any nameable server.
The scope is ours. We measure Europe first; a tree built on another inventory would have other roots. See the map's method.

The data

Everything shown here can be recomputed from this file, published under CC BY 4.0:

the dependency tree for the campaign of 2026-08-07 (JSON) — nodes, edges, clocks, resolved and unresolved digests, each with its reason; its picture (SVG) — which we no longer show on this page, since a server publishes only one upstream at a time, but which we keep producing so that links already cited stay valid — and the most recent campaign, at that stable address
the measured inventory (CSV)

Is your server missing? Declare it in our open repository: the wider the inventory, the fewer anonymous upstreams remain in this tree.

Free NTP Tools

Three independent tools to diagnose your time synchronization:

What these chains imply

This tree says who follows whom. It does not say whether that link is authenticated — a refid names a source, never a transport. What that limit means for auditing and traceability is treated separately: must NTS be proven end to end?