NTP stands for Network Time Protocol, a system that synchronizes clocks across computers and devices on a network. It keeps machines aligned to within a few milliseconds of Coordinated Universal Time (UTC), which is the global standard for timekeeping. NTP communicates over port 123 and is one of the oldest internet protocols still in wide use.
Why Clock Synchronization Matters
Computers have internal clocks, but those clocks drift. A typical computer clock might gain or lose several seconds per day. That sounds minor, but when thousands of machines need to coordinate, even small discrepancies cause real problems. Security certificates can be rejected if a server’s clock is wrong. Financial transactions get logged out of order. Database entries conflict. Log files from different servers become impossible to compare during troubleshooting.
NTP solves this by continuously checking a computer’s clock against reliable time sources and making small, gradual corrections. Rather than snapping the clock to the correct time all at once (which could confuse running software), NTP speeds up or slows down the clock incrementally until it converges on the right time.
How NTP Calculates the Correct Time
The core challenge NTP faces is that network communication isn’t instant. A message from your computer to a time server and back might take 5 milliseconds, 50 milliseconds, or more, depending on network conditions. NTP accounts for this by exchanging four timestamps during each synchronization exchange: when the request left your machine, when the server received it, when the server sent its reply, and when your machine got the reply back.
From those four timestamps, NTP calculates two values. The first is the round-trip delay: how long the message spent traveling through the network. The second is the clock offset: how far your clock is from the server’s clock. By factoring out travel time, NTP can estimate the true time difference with surprising precision.
On a local network under good conditions, NTP achieves accuracy better than one millisecond. Over the public internet, it typically keeps clocks within tens of milliseconds of UTC. Uneven network routes or heavy congestion can push errors to 100 milliseconds or more, but for most purposes that’s still remarkably tight.
The Stratum Hierarchy
NTP organizes time sources into layers called strata. At the top are stratum 0 devices: atomic clocks, GPS receivers, and other high-precision references that aren’t directly accessible over a network. Stratum 1 servers connect directly to these reference clocks via satellite, radio, or dedicated links. They serve as the primary time sources for the rest of the network.
Stratum 2 servers synchronize to stratum 1 servers, stratum 3 servers synchronize to stratum 2, and so on. Each step down the chain adds a small amount of potential error, but the hierarchy provides redundancy. If one server goes offline or starts reporting bad time, clients can fall back to others. Most computers you’d encounter in everyday use are syncing to stratum 2 or stratum 3 servers.
Filtering Out Bad Time Sources
NTP doesn’t blindly trust any single server. When a client queries multiple time sources, those sources might disagree slightly. NTP uses a selection algorithm (based on work by mathematician Keith Marzullo) to figure out which servers are reporting accurately and which are outliers.
The algorithm works by looking at the range of possible correct times reported by each server. It finds the overlap, the window where the most servers agree. Servers whose reported times fall within that window are considered trustworthy (“truechimers” in NTP terminology). Servers outside it are flagged as unreliable (“falsetickers”) and excluded. For the system to consider its time valid, more than half of the servers it’s checking must agree. This design makes NTP resilient to individual servers that malfunction or get compromised.
NTP Version 4: The Current Standard
The current version, NTPv4, is defined in RFC 5905 and brought several meaningful upgrades over its predecessor. Time resolution improved to better than one nanosecond internally, and the discipline algorithm (the part that gradually corrects clock drift) became more responsive to hardware fluctuations. NTPv4 also supports IPv6, the newer internet addressing system, and introduced a dynamic server discovery feature called manycast that lets clients automatically find nearby time servers without manual configuration.
Poll intervals also expanded significantly. NTPv3 maxed out at checking the server every 1,024 seconds (about 17 minutes). NTPv4 can stretch intervals to 36 hours while still maintaining accuracy within tens of milliseconds. This reduces network traffic substantially in large deployments. NTPv4 also added public key authentication through a system called Autokey, supplementing the older symmetric key approach carried over from version 3.
NTP vs. SNTP
Simple Network Time Protocol (SNTP) is a stripped-down version of NTP that uses the same packet format but skips the advanced algorithms. It operates strictly as a client asking a server for the time, without peer-to-peer relationships, sophisticated error correction, or redundant source management.
SNTP is a good fit for devices with limited processing power and memory, like embedded systems, IoT sensors, or simple appliances that just need to be roughly accurate. Full NTP is the better choice when precision matters, when you need fault tolerance from multiple time sources, or when security and authentication are requirements. SNTP implementations typically lack authentication features entirely, making them more vulnerable to receiving false time data.
Security Risks
NTP’s widespread deployment has made it a target for abuse. The most notable attack type is NTP amplification, a form of distributed denial-of-service (DDoS) attack. In this technique, an attacker sends a small request to a public NTP server with a forged return address (the victim’s address). The server responds with a much larger reply, which floods the victim with traffic they never asked for.
The specific vulnerability that enabled the worst of these attacks involved a monitoring command called “monlist,” which returned a list of up to 600 IP addresses that had recently connected to the server. A tiny request could generate a massive response, and because the data came from legitimate servers, it was especially hard to filter. The fix was straightforward: NTP versions 4.2.7 and later disabled the monlist feature by default. Older servers can be protected by adding configuration rules that block external monitoring queries.
More broadly, the NTP community has developed Network Time Security (NTS), a newer authentication layer designed to verify that time data actually came from the server you intended to query and wasn’t tampered with in transit.