When most people first learn about the Network Time Protocol (NTP), they imagine something simple:
My computer asks a time server for the current time, receives an answer, and updates its clock.
Unfortunately, that approach would produce inaccurate clocks.
Network Time Protocol (NTP) is a networking protocol that synchronizes the clocks of computers and network devices over IP networks. Rather than simply requesting the current time, NTP estimates network delay, compensates for clock drift, and continuously adjusts the system clock to keep computers synchronized as accurately as possible.
The real challenge isn't obtaining the time. It's determining how much network latency affected the answer. Solving that problem is why NTP remains one of the most elegant and widely used protocols in distributed systems.
In this comprehensive guide, you'll learn how NTP works, why accurate time is important, how NTP calculates clock offset and network delay using four timestamps.
Additionally, you will also learn why NTP queries multiple time servers, and how it keeps clocks synchronized despite imperfect hardware and unpredictable networks.
First, we will begin with what exactly NTP is.
Table of Contents
What Is Network Time Protocol (NTP)?
The Network Time Protocol (NTP) is a networking protocol used to synchronize the clocks of computers and other devices over IP networks. It estimates network delay, compensates for clock drift, and continuously adjusts the system clock so that participating devices maintain a common notion of time.
Rather than simply asking a server for the current time, NTP exchanges multiple timestamps, filters inaccurate measurements, and gradually disciplines the local clock. This allows computers on the Internet to stay synchronized within milliseconds under normal conditions.
Why Accurate Time Matters
Modern computers rely on accurate time for far more than displaying the correct date and time. Nearly every distributed system assumes that participating machines have clocks that are reasonably synchronized.
Even a difference of a few seconds can cause authentication failures, incorrect log ordering, failed scheduled tasks, or inconsistent data across servers.
Accurate time is essential for many everyday technologies, including:
- Web security: HTTPS and TLS certificates have validity periods. If a system clock is significantly incorrect, browsers and applications may reject otherwise valid certificates.
- System logging: Administrators use timestamps to troubleshoot problems and investigate security incidents. Unsynchronized clocks make it difficult to reconstruct the correct sequence of events across multiple systems.
- Distributed systems: Databases, message queues, and distributed applications often rely on timestamps to coordinate operations, detect conflicts, and order events.
- Scheduled tasks: Cron jobs, automated backups, software updates, and maintenance windows all depend on accurate system time.
- Authentication protocols: Security mechanisms such as Kerberos use timestamps to prevent replay attacks. Large clock differences can cause authentication requests to fail.
- Financial systems: Banks, stock exchanges, and payment processors require precise timestamps for auditing, regulatory compliance, and transaction ordering.
- Monitoring and observability: Monitoring platforms correlate metrics, logs, and traces collected from many machines. Consistent timestamps make it possible to identify the root cause of outages.
Although perfect synchronization is impossible over a network, NTP keeps clocks sufficiently close for most applications by continuously estimating network delay, correcting clock drift, and gradually adjusting the local system clock.
Key takeaway: Accurate time is a foundational requirement for reliable, secure, and distributed computing. NTP exists because maintaining synchronized clocks across imperfect networks is much harder than simply asking another computer for the current time.
Does NTP Use Atomic Clocks?
Not directly.
Most computers never communicate with an atomic clock. Instead, time is distributed through a hierarchy.
Atomic clock / GPS reference
│
▼
Stratum 1 servers
│
▼
Stratum 2 servers
│
▼
Stratum 3 servers
│
▼
Your Linux system
A Stratum 1 server is connected to an authoritative reference clock, such as a GPS receiver or another precision time source. Your computer typically synchronizes with Stratum 2 or Stratum 3 servers, which inherit their time from servers higher in the hierarchy.
Key takeaway: Your computer does not need an atomic clock. It only needs a trustworthy chain leading back to one.
Clock Skew vs. Clock Drift
These two terms are often confused.
Clock skew is the difference between two clocks at a particular moment.
For example:
Computer A: 10:00:05
Computer B: 10:00:00
Clock skew = 5 seconds
Clock drift describes how quickly a clock gains or loses time because its hardware oscillator is imperfect.
Even high-quality quartz oscillators drift by a few parts per million, causing clocks to slowly diverge if left unsynchronized.
Why Simply Asking for the Time Doesn't Work
Imagine your computer sends this request:
"What time is it?"
The server replies:
"12:00:00"
But by the time the reply reaches your computer:
- Was the network delay 2 ms?
- 20 ms?
- 200 ms?
Without knowing that delay, the timestamp alone is insufficient.
This is the fundamental synchronization problem in distributed systems.
How NTP Estimates Network Delay
Rather than exchanging a single timestamp, NTP exchanges four.
Client Server
t1 ---------------------->
receives at t2
replies at t3
<----------------------- t4
Where:
- t1 = client sends request
- t2 = server receives request
- t3 = server sends reply
- t4 = client receives reply
Using these four timestamps, the client estimates two key values:
Round-trip delay
δ = (t4 − t1) − (t3 − t2)
Clock offset
θ = ((t2 − t1) + (t3 − t4)) / 2
These equations allow the client to estimate both the communication delay and how far its clock differs from the server's.
How NTP Selects the Best Time Server
One of the biggest misconceptions about the Network Time Protocol (NTP) is that it simply contacts the nearest or lowest Stratum server and trusts whatever time it reports.
In reality, NTP is much more cautious.
Computer networks are inherently unreliable. Packets can be delayed by congestion, servers can be misconfigured, hardware clocks can drift, and even highly accurate time servers can temporarily provide poor measurements because of network conditions.
To achieve reliable synchronization, NTP evaluates multiple time sources and continuously determines which one is the most trustworthy.
Step 1: Query Multiple Time Servers
Instead of relying on a single server, an NTP client is typically configured to communicate with several independent time servers.
Each server returns its current time, allowing the client to compare multiple measurements rather than blindly trusting a single source.
Server A
\
Server B -----> Your Computer
/
Server C
Using multiple servers improves both accuracy and fault tolerance. If one server becomes unavailable or starts reporting incorrect time, the client can continue synchronizing with the remaining servers.
Step 2: Measure Network Delay and Clock Offset
For every server it contacts, NTP calculates two important values:
- Network delay: the estimated time required for messages to travel between the client and the server.
- Clock offset: the estimated difference between the client's clock and the server's clock.
These measurements help the client determine not only what time the server reports, but also how reliable that measurement is.
A server with a very large or highly variable network delay is generally less suitable for synchronization than one with a stable, low-latency connection.
Step 3: Reject Unreliable Time Sources
Not every server should be trusted.
A server may report incorrect time because of:
- Hardware failures
- Configuration errors
- Excessive network congestion
- Temporary network problems
- Loss of synchronization with its own upstream time source
Suppose an NTP client receives the following clock offsets:
| Time Server | Estimated Offset |
|---|---|
| Server A | +8 ms |
| Server B | +9 ms |
| Server C | +10 ms |
| Server D | +430 ms |
Since three servers closely agree while one differs significantly, NTP identifies Server D as an outlier and excludes it from the synchronization process.
This filtering process helps prevent a single faulty server from causing the client to set an incorrect system time.
Step 4: Select the Best Synchronization Source
After filtering unreliable measurements, NTP selects the server that is most likely to provide accurate and stable time.
The decision is based on several factors, including:
- Low network delay
- Consistent measurements over time
- Stable clock behavior
- Stratum level
- Overall synchronization quality
A common misconception is that a Stratum 1 server is always the best choice.
In practice, this is not necessarily true.
For example, a nearby Stratum 2 server connected over a fast, low-latency network may provide more accurate synchronization than a distant Stratum 1 server reached through a slow or congested Internet connection.
NTP therefore evaluates the overall quality of each synchronization source instead of simply choosing the server with the lowest Stratum number.
Why This Matters
Without these selection and filtering mechanisms, even a single faulty server could cause thousands of computers to adopt an incorrect system time.
By comparing multiple independent time sources, rejecting inconsistent measurements, and continuously re-evaluating synchronization quality, NTP remains resilient even when individual servers or network paths become unreliable.
Key takeaway: NTP doesn't simply choose the closest or lowest Stratum server. It continuously compares multiple time sources, filters unreliable measurements, and synchronizes with the server that provides the most accurate and stable time under current network conditions.
Why NTP Usually Doesn't Jump the Clock
Suppose your computer discovers that it is five seconds fast.
A naive implementation would immediately move the clock backward.
Unfortunately, that can cause problems for:
- databases
- scheduled jobs
- log files
- TLS certificates
- distributed applications
Instead, NTP usually slews the clock.
Rather than changing the displayed time instantly, it slightly speeds up or slows down the system clock until it converges on the correct time.
Large errors may still require a step, but normal operation relies on gradual adjustment through clock discipline algorithms.
How Accurate Is NTP?
On a stable local-area network (LAN), NTP can often synchronize clocks to within a few milliseconds or better.
Over the public Internet, accuracy is typically within tens of milliseconds, depending on network latency, congestion, server quality, and hardware.
Can NTP Work Without the Internet?
Yes. NTP does not require an Internet connection.
Organizations often deploy their own internal NTP infrastructure for reliability and security. An internal NTP server may synchronize with:
- A GPS receiver
- An atomic reference clock
- Another trusted internal NTP server
Air-gapped networks, industrial control systems, military environments, and research laboratories commonly use local NTP servers to maintain accurate time without Internet access.
Why Distributed Systems Treat Time Synchronization as a Hard Problem
At first glance, a master-worker architecture appears sufficient.
Master
/ | \
A B C
However, reality introduces several complications:
- every client experiences different network latency
- network latency constantly changes
- clocks drift continuously
- servers can fail
- some servers may report incorrect time
NTP addresses these issues by combining delay estimation, statistical filtering, multiple time sources, and continuous clock discipline instead of blindly trusting a single master.
This is why textbooks devote entire chapters to clock synchronization. The protocol is solving far more than "asking a server for the time."
Why Doesn't NTP Make Every Computer Show Exactly the Same Time?
Perfect synchronization across a network is impossible.
Every NTP packet experiences slightly different delays due to:
- Network congestion
- Router queues
- Variable transmission times
- Processing delays
- Clock drift inside each computer
NTP minimizes these errors using statistical filtering and continuous clock adjustments, but it cannot eliminate uncertainty entirely. Instead of achieving perfect synchronization, its goal is to keep clocks close enough for reliable operation.
Common Misconceptions About NTP
| Myth | Reality |
|---|---|
| NTP uses atomic clocks directly | Most clients synchronize through a hierarchy of servers. |
| Stratum 1 is always the most accurate | Network latency and server quality matter too. |
| NTP simply asks a server for the time | It estimates delay and offset using four timestamps. |
| NTP keeps clocks perfectly synchronized | It minimizes error but cannot eliminate uncertainty. |
| Lower stratum always means better accuracy | A nearby Stratum 2 or 3 server may outperform a distant Stratum 1 server. |
Frequently Asked Questions (FAQ)
A: Network Time Protocol (NTP) is a networking protocol that synchronizes the clocks of computers and network devices over IP networks. It estimates network delay, compensates for clock drift, and continuously adjusts the local clock so that systems maintain a common notion of time.
A: NTP exchanges four timestamps between a client and a time server. Using these timestamps, it estimates the round-trip network delay and the difference between the client and server clocks (clock offset). The client then gradually adjusts its clock to minimize the error.
A: Yes. Most modern Linux distributions synchronize time using NTP-compatible software such as chronyd (Chrony) or systemd-timesyncd. Both automatically maintain accurate system time by synchronizing with trusted NTP servers, although Chrony generally provides better performance on systems with intermittent network connectivity or variable clock drift.
A: Most computers never communicate directly with an atomic clock. Instead, they synchronize with NTP servers that ultimately trace their time back to highly accurate reference clocks, such as atomic clocks or GPS-disciplined clocks. This hierarchy allows accurate time to be distributed efficiently across the Internet.
A: Clock skew is the difference between the current readings of two clocks at a specific moment.
Clock drift describes how quickly a clock gains or loses time because its hardware oscillator is not perfectly accurate. Drift causes skew to increase over time if clocks are not periodically synchronized.
A: A single timestamp cannot distinguish between the current time and the network delay required to deliver it. By exchanging four timestamps, NTP estimates both the communication delay and the clock offset, allowing much more accurate synchronization.
A: The four timestamps are:
- T1: Client sends the request.
- T2: Server receives the request.
- T3: Server sends the response.
- T4: Client receives the response.
These timestamps allow the client to calculate the network delay and clock offset.
A: Suddenly moving the system clock backward or forward can disrupt applications, databases, scheduled tasks, and log files. Instead, NTP usually slews the clock by slightly changing its speed until it matches the correct time. Large errors may still require the clock to be stepped.
A: Network delays, hardware failures, and incorrect server configurations can produce inaccurate time measurements. NTP compares responses from multiple servers, filters out unreliable results, and selects the most trustworthy time source to improve accuracy and resilience.
A: A Stratum indicates a server's distance from an authoritative reference clock:
- Stratum 0: Reference clocks such as atomic clocks or GPS receivers (not directly accessible over the network).
- Stratum 1: Servers directly connected to Stratum 0 reference clocks.
- Stratum 2: Servers synchronized to Stratum 1 servers.
- Stratum 3 and below: Servers synchronized to higher-stratum servers.
A lower stratum generally indicates fewer synchronization hops, but it does not automatically guarantee better accuracy. Network conditions and server quality also play important roles.
A: NTP is designed for general-purpose time synchronization over IP networks and is suitable for most servers, desktops, and network devices.
Precision Time Protocol (PTP) is designed for environments requiring much higher precision, often in the microsecond or nanosecond range, such as telecommunications, industrial automation, scientific research, and high-frequency trading. PTP usually requires hardware timestamping and specialized network support.
A: If NTP is unavailable, the system clock continues running using its local hardware oscillator. Because no oscillator is perfectly accurate, the clock gradually drifts away from the correct time.
Over time, this can lead to:
- Authentication failures (such as Kerberos)
- HTTPS certificate validation errors
- Incorrect timestamps in log files
- Missed scheduled tasks
- Problems correlating events across multiple servers
- Data inconsistencies in distributed systems
The longer synchronization is unavailable, the larger the clock error typically becomes.
A: Yes. Estimating network latency is one of NTP's primary functions.
Instead of trusting a single timestamp, NTP exchanges four timestamps between the client and the server. These timestamps allow the client to estimate both the round-trip network delay and the difference between its own clock and the server's clock.
Because network latency changes continuously, NTP performs this process repeatedly and continuously refines its estimate rather than assuming the delay is constant.
A: NTP uses the User Datagram Protocol (UDP) rather than TCP.
UDP is well suited for time synchronization because it has lower overhead and avoids retransmissions that could introduce additional and unpredictable delays. Since NTP periodically exchanges small packets, occasional packet loss has little impact because the next synchronization cycle quickly updates the clock.
A: NTP uses UDP port 123 for both client and server communication.
When configuring firewalls or network security policies, UDP port 123 must be allowed between NTP clients and their time servers. Blocking this port prevents systems from synchronizing their clocks.
ntpd?A: Both Chrony and ntpd implement the Network Time Protocol, but they are optimized for different environments.
Chrony generally provides:
- Faster synchronization after startup
- Better performance on laptops and virtual machines
- Improved handling of intermittent network connections
- Better compensation for systems with unstable clock driftntpd is the traditional NTP daemon that has been used on Unix and Linux systems for decades. While it remains widely supported, many modern Linux distributions now use Chrony as the default time synchronization service because of its improved performance under real-world conditions.
A: GPS satellites continuously broadcast highly accurate timing information derived from onboard atomic clocks.
A GPS receiver connected to an NTP server can use these signals as a highly accurate reference clock. This allows the server to operate as a Stratum 1 time server and distribute accurate time to other systems on the network.
Although many people associate GPS with navigation, precise time distribution is one of its primary functions.
A: A leap second is a one-second adjustment occasionally added to Coordinated Universal Time (UTC) to keep it aligned with Earth's slightly irregular rotation.
Because Earth's rotation is not perfectly constant, UTC occasionally requires adjustment to remain synchronized with astronomical time.
NTP includes mechanisms to notify clients about an upcoming leap second so they can handle the adjustment correctly.
Some organizations also use techniques such as leap smearing, which gradually spreads the adjustment over a longer period to avoid sudden one-second jumps that could disrupt distributed applications.
Conclusion
One of the biggest lessons from studying distributed systems is that time is surprisingly difficult.
NTP succeeds not because it has access to atomic clocks, but because it carefully estimates uncertainty, filters unreliable measurements, and continuously corrects for hardware imperfections.
That combination allows millions of computers to maintain remarkably accurate clocks despite unreliable networks and imperfect hardware.
Related Read:
- How To Set Up Time Synchronization On Ubuntu
- How To Set Date And Time From Command Line In Linux
- Monitor Network Latency In Linux Using Ping, Mtr and Smokeping
Resource:
