← Back to Learning Hub

Office/Network Fixes • Intermediate • 5 min read

NTP Stratum Levels Explained: Stratum 0 to 15

NTP stratum levels rank time servers by distance from a reference clock. Learn what stratum 0 through 15 mean and how to check any server's stratum.

NTP stratum is a number from 0 to 15 that tells you how many hops a time server sits from a reference clock. Stratum 0 is the clock itself, stratum 1 is a server wired directly to that clock, and every hop after that adds one. Stratum 16 means the server is unsynchronized and should not be trusted. Lower means closer to the source, not automatically more accurate, and that distinction matters when you pick servers.

What the stratum number actually measures

Stratum counts distance from a reference clock, nothing more. It is not a quality score. A stratum 2 server one millisecond away on your LAN will usually give you better time than a stratum 1 server sitting behind a congested transatlantic link. NTP uses the stratum value for two jobs: it prefers lower strata when several candidates look equally healthy, and it caps the chain at 15 hops to stop synchronization loops from forming. Treat it as a pedigree, then judge accuracy by delay and jitter.

Stratum 0: the reference clocks

Stratum 0 devices are the actual timekeepers: cesium and rubidium atomic clocks, GPS receivers, and radio clocks that pick up broadcast signals like DCF77 or WWVB. You never talk to a stratum 0 device over the network. It connects to a computer through a serial port, a PPS pin, or a dedicated card, and that computer becomes stratum 1.

Stratum 1: primary time servers

A stratum 1 server has a direct, non-network connection to a stratum 0 clock. National labs such as NIST and PTB run public stratum 1 servers, and plenty of teams build their own with a cheap GPS module and a Raspberry Pi. These machines anchor the whole hierarchy, and good ones hold time within a few microseconds of UTC.

Stratum 2 and 3: the workhorses

A stratum 2 server syncs to one or more stratum 1 servers over the network. A stratum 3 server syncs to stratum 2, and so on down the chain. Most servers in the public NTP Pool sit at stratum 2 or 3, and that is where almost every client should be pointed. A well run stratum 2 server typically stays within a millisecond or two of UTC, which is far tighter than anything a normal application can notice.

Stratum 4 through 15: the long tail

Each extra tier adds a hop and a little error. You see stratum 4 and 5 inside large organizations that chain internal servers on purpose: a pair of stratum 2 machines at the core, stratum 3 relays per site, stratum 4 for isolated segments. That layering is deliberate and fine. Anything beyond stratum 5 or 6 usually signals a misconfiguration, such as clients daisy chaining off each other instead of pointing at the internal pool. The protocol allows values up to 15, but nobody designs a chain that deep.

Stratum 16: unsynchronized

Stratum 16 is the no-time marker. A freshly booted server reports 16 until it locks onto a source, and a server whose upstreams have all failed eventually falls back to it. Clients ignore stratum 16 servers entirely. If monitoring shows a machine stuck at 16 for more than a few minutes, its NTP configuration is broken, its sources are unreachable, or a firewall is dropping UDP port 123.

How to check a server's stratum

The command depends on which time daemon the box runs.

With chrony on modern Linux

Run chronyc tracking. The Stratum line shows the stratum of the machine itself, and the Reference ID line shows which source it follows. Run chronyc sources to see the stratum of every configured upstream in the second column.

With ntpd

Run ntpq -p. The st column lists the stratum of each peer, and the row marked with an asterisk is the source currently selected. For the machine's own stratum, run ntpq -c rv and read the stratum field in the output.

On Windows

Run w32tm /query /status in an elevated prompt. The output includes a Stratum line plus the current source and the last successful sync. w32tm /query /peers shows each configured peer.

Checking a remote server

To check a server you do not control, query it directly with ntpdate -q pool.ntp.org or sntp pool.ntp.org, swapping in the hostname you care about. The response packet carries the server's stratum, so a single query tells you where it sits in the hierarchy.

Which stratum you should sync to

Point clients at stratum 2 or 3 and stop worrying. Reserve public stratum 1 servers for infrastructure that feeds many downstream clients, since hammering them from every laptop is bad citizenship and buys you nothing measurable. Configure at least three sources so NTP can outvote a false ticker, and four is better because quorum survives one failure. If you run more than a handful of machines, stand up two internal stratum 2 or 3 servers, sync them to the pool, and point everything else at those. Your clocks stay tight, your firewall rules stay short, and a WAN outage no longer scatters your fleet's time.

Stratum is a distance marker, and once you can read it, the output of ntpq -p and chronyc tracking turns from noise into a map. Check delay and jitter alongside it, keep your chain short, and reliable time mostly takes care of itself. When DNS is the other half of your infrastructure checklist, Valla DNS covers that side.

Troubleshooting box

If results look inconsistent, compare authoritative nameservers first, then recursive resolvers by region. Capture snapshots every 10 minutes for deterministic incident timelines.

Try VallaDNS free →