How network time works

Every computer has a clock, and no two clocks run at exactly the same speed. The NTP specification assumes that a computer’s clock may be off in frequency by up to 15 parts per million, which, as it notes, “amounts to about 1.3 s per day”. Left alone, clocks on different machines drift apart day by day.

Correct time matters more than it seems. Log files from different machines can only be compared if their clocks agree. TLS certificates are valid only between two dates (RFC 5280), so a device with a badly wrong clock may reject valid certificates or accept expired ones. And time-based one-time login codes (RFC 6238) only work if both sides agree on the time.

The Network Time Protocol (NTP) keeps clocks in step over the network. It was first described by David L. Mills in RFC 958 in September 1985; the current version, NTPv4, is specified in RFC 5905 (2010). This article explains how it measures time across a network whose delays it does not know, and how it decides whom to trust.

A hierarchy of clocks

NTP servers form a hierarchy. Each level is a stratum, a term RFC 5905 borrows loosely from the telephone industry:

A server’s stratum is one more than the stratum of the server it synchronizes to. RFC 5905 notes that errors “increase approximately in proportion to stratum numbers and measured round-trip delay”, so a client prefers servers that are close, both in the hierarchy and on the network.

Four timestamps

The core of NTP is one simple exchange. A client and a server each have a clock, and the client wants to know how far apart they are, the offset. The network delay is unknown, but the exchange records four timestamps:

• T1: the client’s clock when it sends the request,
• T2: the server’s clock when the request arrives,
• T3: the server’s clock when it sends the response,
• T4: the client’s clock when the response arrives.

From these, RFC 5905 computes the offset θ of the server’s clock relative to the client’s, and the round-trip delay δ:

offset  θ = ((T2 − T1) + (T3 − T4)) / 2
delay   δ = (T4 − T1) − (T3 − T2)

The delay is the total time minus the time the server spent between receiving and answering. The offset formula averages the two directions, and the network delay cancels out, as long as it is the same in both directions. An example: the client’s clock is 100 ms behind, each direction takes 30 ms, and the server takes 1 ms to answer.

T1 = 0.000   T2 = 0.130   T3 = 0.131   T4 = 0.061     (seconds)

θ = ((0.130 − 0.000) + (0.131 − 0.061)) / 2 = 0.100   the server is 100 ms ahead
δ = (0.061 − 0.000) − (0.131 − 0.130)       = 0.060   60 ms of network delay

The limit: asymmetric paths

The formula cannot know how the delay was split between the two directions; it assumes an even split. If the request in the example had taken 50 ms and the response only 10 ms, the timestamps would be T2 = 0.150, T3 = 0.151 and T4 = 0.061. The delay is still 60 ms, but the computed offset becomes 0.120 instead of 0.100: an error of 20 ms, half the difference between the two directions.

In the worst case, all of the delay is on one side, and the error is half the round-trip delay. This is why NTP’s measure of how much a source can be trusted, its synchronization distance, includes half the delay (RFC 5905), and why nearby servers with short round trips give better time.

Whom to trust

A careful client asks several servers, and some of them may be wrong. RFC 5905 calls servers with incorrect time falsetickers and good ones truechimers. Its selection algorithm treats each server’s answer as an interval, the offset plus or minus its possible error, and looks for the largest group of servers whose intervals overlap. Servers outside that majority are discarded as falsetickers; the survivors are combined into the final offset.

This only works with enough servers. With two that disagree, a client cannot tell which one is wrong. RFC 8633, the best current practice for NTP, says that operators who care about accurate time “SHOULD use at least four independent, diverse sources of time”, so that one can fail and three remain.

Adjusting the clock

Knowing the offset, NTP corrects the clock in one of two ways (RFC 5905):

• If the offset is below the step threshold of 125 ms, NTP adjusts the clock gradually, speeding it up or slowing it down, so time never jumps and never runs backwards.
• If the offset is larger, it steps the clock to the correct time at once.
• If the offset exceeds the panic threshold of 1,000 seconds, something is badly wrong, and the program should stop with a message rather than move the clock that far.

NTP also learns how fast the local clock drifts and corrects its frequency, so the clock stays close even between exchanges. Once the clock is stable, the client asks less often: NTPv4 polls between every 16 seconds and every 36 hours. RFC 5905 states that typical primary servers are “precise within a few tens of microseconds”, and that clients on fast local networks stay within a few hundred microseconds.

Timestamps, 2036 and leap seconds

NTP timestamps are 64 bits long: 32 bits of seconds since 1 January 1900 and 32 bits of fractions of a second, a resolution of about 233 picoseconds.

Thirty-two bits of seconds last 2³² seconds, about 136 years, so the counter wraps around on 7 February 2036 at 06:28:16 UTC. RFC 5905 plans for this: time is divided into eras, era 0 from 1900 to 2036 and era 1 after it. Because the offset calculation uses differences between timestamps, it keeps working across the boundary as long as the client’s clock is already within 34 years (68 years with floating-point arithmetic) of the correct time.

Leap seconds keep UTC, an atomic time scale, within 0.9 seconds of UT1, which follows the Earth’s rotation. They are announced by the International Earth Rotation and Reference Systems Service when needed, and every one since the practice began in 1972 has added a second (RFC 8633). NTP announces them in advance with a two-bit leap indicator in every packet: 1 means the last minute of the day will have 61 seconds, 2 means it will have 59. Some operators instead smear a leap second, spreading the change over a window of hours; RFC 8633 reports windows of two to twenty-four hours. It also warns against mixing smeared and non-smeared servers, because they disagree by up to a second during the window.

Securing time

Plain NTP packets are not protected: an attacker on the path can change them, or replay old ones, and shift a client’s clock. Two standards address this.

• Port randomization (RFC 9109): clients should send from a random port instead of the well-known NTP port 123, which makes it harder for an attacker off the path to inject fake responses.
• Network Time Security (NTS, RFC 8915): the client first connects to the server with TLS over TCP port 4460, the NTS key establishment, which verifies the server’s identity with a certificate and agrees on keys. After that, every NTP packet carries extension fields that authenticate it, protect against replay and prove that the response belongs to the request. The server keeps no state per client: it hands the client opaque cookies that the client returns with each request.

NTS also avoids becoming a tool for attacks: a server never responds with a packet larger than the request, so it cannot be used to amplify denial-of-service traffic. For higher accuracy, RFC 9769 (2025) adds interleaved modes, in which a server sends the precise transmit time of a packet in the following one, when it is known exactly.

Key points

• Computer clocks drift, by about a second a day in NTP’s assumptions, so they must be corrected over the network.
• NTP servers form a hierarchy of strata, from stratum 1 servers with reference clocks such as GPS down to stratum 15.
• Each exchange records four timestamps; the offset is ((T2 − T1) + (T3 − T4)) / 2 and the delay (T4 − T1) − (T3 − T2). Asymmetric paths cause an error of up to half the delay.
• With several servers, NTP discards falsetickers and averages the truechimers; use at least four sources.
• Small errors are corrected by slowly adjusting the clock, large ones by stepping it.
• NTP’s 32-bit seconds wrap around in 2036, which the protocol handles with eras.
• NTS (RFC 8915) authenticates time with keys agreed over TLS.