The Network Time Protocol (NTP) synchronizes clocks across computers by exchanging timestamps over a network, then calculating the difference between each machine’s clock and a reference time source. It runs over UDP on port 123 and can keep computers accurate to within a few milliseconds of each other over the public internet. The current version, NTPv4, is defined in RFC 5905 and is backwards compatible with earlier versions.
The Four-Timestamp Exchange
At its core, NTP works by recording four precise timestamps during a single exchange between a client and a server. When your computer wants to check the time, it sends a request to a time server and notes the exact moment of departure (T1). The server records when that request arrives (T2), then records when it sends its reply (T3). Finally, your computer records when the reply arrives back (T4).
From these four timestamps, NTP calculates two critical values. The round-trip delay is the total travel time of the packets minus the time the server spent processing: (T4 − T1) − (T3 − T2). The clock offset, which tells your computer how far off its clock is, uses the same four values: ((T2 − T1) + (T3 − T4)) / 2. This formula assumes the network delay is roughly equal in both directions. That assumption isn’t always perfect, but the worst-case error in reading a remote server’s clock can’t exceed half the round-trip delay. So a packet that takes 20 milliseconds to make the round trip introduces at most 10 milliseconds of potential error.
The Stratum Hierarchy
NTP organizes time sources into layers called strata. Stratum 0 devices are the actual precision timekeeping hardware: atomic clocks, GPS receivers, and radio clocks that receive signals from national time standards. These devices don’t connect to the network directly. Instead, they feed their time to Stratum 1 servers, which are the highest-accuracy time sources available on a network. Major organizations and national time services maintain Stratum 1 servers.
From there, the hierarchy cascades. Stratum 2 servers synchronize with Stratum 1 servers, Stratum 3 servers synchronize with Stratum 2, and so on down to Stratum 15, which is the lowest valid level. Stratum 16 is a special designation meaning “unsynchronized.” Each step down the hierarchy adds a small amount of potential error. For most purposes, Stratum 2 or 3 servers are more than adequate. Organizations often deploy servers across multiple strata so that if a primary time source fails, lower-tier servers can still maintain accurate time.
Filtering Out Bad Samples
A single timestamp exchange can be thrown off by network congestion, routing changes, or brief delays in the operating system. NTP doesn’t trust any one measurement. Instead, it uses a clock filter algorithm that collects several offset and delay samples over a window of exchanges, then picks the offset associated with the shortest round-trip delay. The logic is straightforward: a shorter round trip means less opportunity for asymmetric delays to distort the result, so that sample is most likely to be accurate.
Choosing Between Multiple Servers
Most NTP configurations point to several time servers at once. This creates a new problem: if the servers disagree, which ones do you trust? NTP solves this with an algorithm originally devised by Keith Marzullo. Each server’s measurement produces a range of possible correct times (called a correctness interval), calculated from its reported offset and an estimate of its total error. The algorithm looks for the narrowest range that overlaps with the largest number of these intervals.
Servers whose intervals overlap with this common range are classified as “truechimers,” meaning they’re likely reporting accurate time. Servers whose intervals fall entirely outside it are classified as “falsetickers” and get excluded. The system requires that more than half of all servers qualify as truechimers for the result to be considered valid. This voting mechanism makes NTP resilient to a single server being wrong, whether from a hardware fault, network problem, or misconfiguration.
How Your Clock Gets Corrected
Once NTP determines the offset between your computer’s clock and the true time, it has to actually fix the clock. How it does this depends on how far off the clock is.
For offsets smaller than 128 milliseconds, NTP “slews” the clock. This means it subtly speeds up or slows down the software clock’s tick rate until the error is gradually erased. Your clock never jumps, and applications that depend on time moving smoothly (like databases or log files) aren’t disrupted. For offsets larger than 128 milliseconds, NTP “steps” the clock, setting it to the correct time in one instant jump. Stepping is faster but can confuse software that expects time to always move forward. During normal operation after the initial sync, offsets stay small enough that slewing handles everything.
Security With NTS
NTP was designed in an era when network security wasn’t a primary concern, and for decades, most NTP traffic traveled without any authentication. An attacker who could intercept or forge NTP packets could shift a target’s clock, potentially undermining security certificates, log integrity, or time-sensitive transactions.
Network Time Security (NTS), defined in RFC 8915, addresses this. It works in two phases. First, the client and server establish a secure connection using TLS (the same encryption technology that protects HTTPS websites). During this handshake, the server’s identity is verified through standard certificate infrastructure, and both sides derive encryption keys. The server also provides the client with a set of opaque cookies. In the second phase, actual time synchronization happens over regular NTP packets, but with added extension fields that carry authentication codes and the cookies. This lets the server verify that each request is legitimate without needing to store any per-client state. The time data itself is sent in the clear since there’s nothing secret about what time it is, but the extension fields can be encrypted to protect metadata.
How NTP Compares to PTP
NTP is the standard for general-purpose time synchronization, but some applications need tighter accuracy. The Precision Time Protocol (PTP, IEEE 1588) fills that role. Where NTP typically achieves accuracy better than 1 millisecond over the internet, PTP can reach below 100 nanoseconds, roughly 10,000 times more precise.
The tradeoff is complexity. NTP runs entirely in software on standard network hardware, and clients pull time from servers on their own schedule. PTP requires dedicated hardware timestamping at network interfaces and often uses specialized network equipment like boundary clocks and transparent clocks to minimize jitter at each hop. PTP masters push time to clients rather than waiting for requests. For anything from keeping your servers’ logs in agreement to coordinating distributed systems, NTP is the practical choice. PTP shows up in telecommunications, financial trading infrastructure, and industrial control systems where microsecond or nanosecond precision matters.