Left alone, the clock in a computer is wrong within a day. Its quartz oscillator is cheap and temperature-sensitive, so it gains or loses seconds without anyone noticing until a certificate fails to validate or a log file makes no sense. NTP exists to stop that happening. The Network Time Protocol is the quiet background service that keeps hundreds of millions of machines within a few milliseconds of Coordinated Universal Time, and almost nobody ever thinks about it.

This article explains how the protocol measures the error between two clocks, what the stratum hierarchy means, how accurate the result actually is across the public internet, and why a well-behaved client corrects your clock gradually instead of jumping it. If you want to know where your own machine stands right now, the clock sync check measures your offset in the browser.

What Is NTP and What Does It Do?

NTP is a protocol for distributing accurate time over a packet network. A client asks a server what time it is, measures how long the exchange took, and uses that measurement to work out both how far its own clock is out and how fast it is running wrong.

It has been in service since the mid-1980s, which makes it one of the oldest internet protocols still running essentially unchanged, and the current version four is defined in RFC 5905. The design assumption is that the network is hostile to timekeeping: packets are delayed unpredictably, servers occasionally lie, and the local oscillator is untrustworthy. Rather than believing any single exchange, an NTP client polls several servers repeatedly, discards the outliers using a selection algorithm, and combines what remains. Polling intervals stretch from around a minute to a day once the clock is behaving. The protocol runs over UDP on port 123, and a query with its reply amounts to only a couple of hundred bytes, which is why a single machine can serve many thousands of clients.

How Does NTP Measure the Offset?

With four timestamps. The client notes when it sent the request, the server notes when it arrived and when it replied, and the client notes when the reply came back. From those four numbers both the round-trip delay and the clock offset fall out arithmetically.

The delay is the total time in flight, found by subtracting the interval the server spent processing from the interval the client observed end to end. The offset is the average of two differences: how far ahead the server appeared to be on the way out, and how far ahead it appeared on the way back. Averaging the two cancels the travel time, provided the path is symmetric. That proviso is the protocol’s central weakness. If a packet takes twelve milliseconds outbound and four returning, the maths silently attributes half the imbalance to the clock, and no amount of repeated measurement will reveal the mistake. NTP clients therefore prefer servers with short, stable, symmetric paths and treat a sudden change in delay as a reason to distrust a sample.

The NTP Stratum Hierarchy

Servers are arranged in layers, and the stratum number simply records how many steps a server sits from a reference clock. Lower is closer to the source, not necessarily more accurate for you.

  • Stratum 0: the reference hardware itself, such as a caesium standard, a GPS receiver or a radio clock. These devices are not on the network; they feed a computer directly.
  • Stratum 1: a server with a stratum 0 device attached, often operated by a national laboratory, a university or a large network provider.
  • Stratum 2: a server synchronised to one or more stratum 1 servers. Most public servers, and most that you should actually use, live here or one level down.
  • Stratum 3 to 15: successive layers, each taking time from the one above. The hierarchy is capped, and stratum 16 is the code for a clock that is not synchronised at all.

The instinct to point every machine at a stratum 1 server is a mistake. A nearby stratum 2 server on a short, stable path will usually give a better result than a distant stratum 1 across congested links, and it spares the upstream servers a load they were never meant to carry. That is the reasoning behind pool.ntp.org, a volunteer network of several thousand servers that hands out addresses by rotating DNS, spreading demand and giving each client a set of independent sources without any manual configuration.

How Accurate Is NTP Over the Internet?

A few milliseconds is the realistic expectation for a machine synchronising to good servers over the public internet. On a local network with a nearby server, sub-millisecond agreement is normal, and a well-tuned server with a directly attached reference can hold microseconds.

The limit is the network, not the protocol. Queuing, asymmetric routing and busy links introduce variable delay, and the offset calculation cannot separate a genuine clock error from a lopsided path. Operating system timestamping adds its own noise, since the moment a packet is stamped in software is not the moment it reaches the wire. Where microseconds or better are required, as in some trading and broadcast systems, the Precision Time Protocol is used instead, with hardware timestamping in the network cards and switches. For almost everything else, the milliseconds NTP delivers are far better than the drift it corrects, described in why computer clocks drift.

Why NTP Slews Instead of Jumping

Jumping a clock breaks software. Databases, log correlation, build systems, certificate checks and file timestamps all assume time moves forward at a steady pace, so a well-behaved NTP client changes the rate of the clock rather than its reading whenever it can.

Slewing means running the clock slightly fast or slow until the error is absorbed, typically at a maximum of about 500 parts per million, roughly half a millisecond of correction per second of running. A tenth of a second of error therefore takes a few minutes to clear, and no application ever sees a discontinuity. Stepping is reserved for larger errors: the traditional threshold is 128 milliseconds, above which the daemon sets the clock outright, and an offset of more than about a thousand seconds is treated as a fault rather than a correction, on the grounds that something is badly wrong. Backwards steps are the ones that cause damage, which is why the protocol works so hard to avoid them.

NTP, UTC and Leap Seconds

The timescale distributed by the protocol is UTC, which means it inherits UTC’s awkward feature: the occasional leap second. A flag in the packet header warns clients in the final hours before an insertion, and a compliant implementation repeats or skips a second at the boundary.

In practice many large operators refuse to repeat a second at all, and instead smear the extra second across several hours by running their servers imperceptibly slow, so no client ever sees a repeated timestamp. A machine synchronised to a smearing server and one synchronised to a strict server will disagree by up to a second during the smear window, which is a genuine hazard when the two are compared. The scheduled end of leap seconds removes the problem entirely, and the background is set out in leap seconds explained. You can compare your device against a plain reading on the current UTC clock.

Conclusion

NTP takes an unreliable quartz oscillator and a lossy network and produces, from both, a clock good to a few milliseconds. It does so by timing its own round trips, choosing carefully among several sources, arranging servers in strata so that load and error both stay bounded, and correcting your clock by changing its rate rather than yanking its hands. Setting it up on your own machine takes a minute, as described in how to sync your computer clock. To see how far out you are before you start, run the clock accuracy check or begin at the atomicclock.now homepage.