What Is NTP and How Computers Stay in Sync Across the Internet

Person working across multiple laptops, a monitor, and a phone at once, representing how NTP keeps every connected device synchronized to the same time

Every phone, laptop, server, and smart device you own agrees on roughly the same time, down to a few milliseconds, without anyone manually setting a single one of them. That quiet agreement runs through a protocol older than the modern web: the Network Time Protocol, designed by one engineer in 1985 and still, four decades later, the invisible infrastructure that keeps the internet’s clocks from drifting apart.

One Engineer’s Protocol From 1985

NTP was created by David L. Mills at the University of Delaware in 1985, originally documented in RFC 958. Computers already had a way to represent time, but representing it and agreeing on it across a network of independent machines are two different problems, and NTP was built specifically to solve the second one. The protocol has been revised twice since, through NTPv3 in RFC 1305 and the current NTPv4, defined in RFC 5905 in 2010. It runs over UDP on port 123, a lightweight, connectionless design choice that keeps synchronization fast but, as later became clear, carries its own risks.

A Hierarchy With Sixteen Levels

NTP organizes time sources into a tree structure called a stratum hierarchy, running from stratum 0 to stratum 15. Stratum 0 devices aren’t actually on the network at all; they’re the reference clocks themselves, the atomic clocks and GPS receivers that define time with extreme precision. Stratum 1 servers connect directly to a stratum 0 device and are the first point where that precision actually reaches the internet. Stratum 2 servers synchronize from stratum 1, stratum 3 from stratum 2, and so on down the chain, with each additional hop introducing a small amount of extra imprecision. Running a stratum 0 or stratum 1 server is expensive and specialized enough that most organizations, and nearly every personal device, simply draw time from a lower stratum instead, which is more than accurate enough for almost anything a computer needs to do.

How Two Clocks Agree Without Sharing One

The actual synchronization relies on a simple four-timestamp exchange. A client sends a request at its own local time, T1. The server receives it at T2 and sends its reply at T3, both stamped with the server’s own clock. The client receives that reply at T4. From those four numbers, NTP can calculate two things at once: the round-trip network delay, (T4βˆ’T1)βˆ’(T3βˆ’T2), and the actual offset between the two clocks, ((T2βˆ’T1)+(T3βˆ’T4))/2. The math assumes the network delay is roughly symmetric, the trip there taking about as long as the trip back, which holds well enough in practice to get useful results even though it isn’t always precisely true. Over the open internet, this typically resolves clocks to within a few milliseconds of each other; on a local network, accuracy often improves to the sub-millisecond or even microsecond range.

Slewing Instead of Snapping

A computer that discovers its clock is wrong doesn’t just jump straight to the correct time, because a sudden jump, especially backward, can break software that assumes time only ever moves forward. Instead, NTP uses two different correction strategies depending on how far off the clock actually is. For small discrepancies, typically under 128 milliseconds, it uses slewing: quietly speeding up or slowing down the clock’s tick rate until the gap closes gradually, invisible to anything running on the machine. For larger discrepancies, usually caused by a machine that’s been offline or badly out of sync for a while, NTP falls back to stepping, an immediate jump straight to the correct time, accepting the small risk of disruption because gradually correcting a multi-second error would simply take too long to be useful.

Not Every Server Gets Believed Equally

A well-configured NTP client doesn’t trust a single server. It queries several at once and has to decide which answers to believe, since a misconfigured or compromised server can report time that’s simply wrong. NTP handles this with an algorithm, based on work by Keith Marzullo, that treats each server’s reported time as a range rather than a single point and looks for the overlap most of them agree on, quietly discarding outliers the protocol calls falsetickers in favor of the truechimers left behind. The whole system is built around UTC, including explicit handling for the occasional leap second, which is part of why NTP has had to be updated as the rules around leap seconds themselves have changed. In practice, most of the world’s devices never talk to a stratum 1 server directly at all; they draw from pool.ntp.org, a large, volunteer-run collection of public servers that has become the de facto backbone for consumer and small-business time synchronization.

The stakes go well beyond a wrong clock face. TLS, the encryption behind nearly every secure website, checks a certificate’s validity window against the local system clock, and a device with badly drifted time can reject perfectly valid certificates or, worse, accept expired ones. Authentication systems built on Kerberos, common across corporate networks, typically refuse to authenticate a request if the client and server clocks disagree by more than a few minutes, treating the mismatch as a possible replay attack. Distributed databases and logging systems lean on synchronized timestamps to determine which of two events actually happened first across different machines. None of these systems were designed with NTP specifically in mind, but nearly all of them silently assume it’s working.

NTP doesn’t just tell your computer what time it is. It tells your computer how much to trust the answer. worldtimedata

The Same Protocol Has Been Weaponized

NTP’s lightweight, connectionless design turned out to have a serious downside. Around 2013, security researchers identified a widespread vulnerability, catalogued as CVE-2013-5211, in an optional NTP feature called monlist, which returns a list of the last 600 clients that queried a server. Attackers realized they could send a tiny, spoofed request to a vulnerable public NTP server and have it fire a response back at a victim’s address that was tens or even hundreds of times larger than the original request, a technique known as an amplification attack. Government cybersecurity agencies issued formal alerts as the technique spread, and the fix was straightforward: NTP version 4.2.7 disabled monlist by default, closing off the exploit for any server running a current version. Older, unpatched servers scattered across the internet, however, remained usable for this kind of attack for years afterward.

When Milliseconds Aren’t Precise Enough

NTP’s millisecond-level accuracy is more than enough for browsing, email, or keeping a calendar app honest, but some industries need far more. High-frequency financial trading is the clearest example: markets that react to scheduled data releases increasingly need to timestamp trades to the microsecond or nanosecond, both for competitive reasons and, in many jurisdictions, for regulatory compliance. For that level of precision, the industry generally turns to a different protocol, the Precision Time Protocol, which uses hardware-level timestamping to shave the uncertainty down from NTP’s milliseconds to fractions of a microsecond. PTP didn’t replace NTP; it exists alongside it, handling the narrow slice of use cases where NTP’s already impressive accuracy simply isn’t tight enough.

An Invisible Standard That Outlived Its Own Update Cycle

David Mills continued working on NTP’s algorithms for decades after writing the original protocol, and by the time of his death in 2024, the system he designed in 1985 was still synchronizing the overwhelming majority of clocks on the internet, largely unnoticed by the billions of people relying on it every day. That combination, foundational and invisible, is common to a lot of internet infrastructure, but NTP is a particularly clean example: the same systems that quietly assume clocks need no attention are exactly the ones that eventually hit an edge case nobody planned for. NTP has spent forty years being the part of the internet nobody thinks about until it’s wrong, which is generally the best compliment a piece of infrastructure can get.

βœ•Close Menu