Network Time Protocol and Why Accurate System Clocks Matter Across Networks

A computer’s clock can look perfectly correct while still being slightly different from the clocks on other devices around it. That difference may seem harmless when you are checking the time on a single PC. Across a network, however, even relatively small clock differences can make events difficult to compare. Consider a simple troubleshooting situation. A server records an authentication failure at 10:14:32, a firewall records the connection at 10:14:29, and another machine records a related event at 10:14:35. If the machines’ clocks are not synchronised, an administrator cannot safely assume that those timestamps reflect the actual order in which events occurred. This is one reason networks use Network Time Protocol (NTP).

NTP allows computers to synchronise their clocks to a common time reference. It does not simply “send the correct time” and leave the computer clock alone. NTP measures timing information over the network and uses it to estimate clock offset and regulate the local system clock. The result is something easy to overlook but fundamental to networked computing: machines can establish a much more consistent timeline.

What is Network Time Protocol?

Network Time Protocol is a protocol for synchronising computer clocks across networks, typically toward a common time scale such as UTC. It is widely used across the Internet and private networks. (NTP: Network Time Protocol)

A typical arrangement contains several roles:

• A time source provides a reference for accurate time.
• An NTP server obtains or maintains synchronised time.
• An NTP client queries one or more servers.
• The client’s operating system uses the measurements to adjust its local clock.

NTP can operate across ordinary IP networks, which makes it practical for everything from individual computers to servers and network infrastructure. The important point is that the local clock remains a local clock. NTP provides information that allows the system to determine how far its clock has drifted and how it should be corrected.

Why computer clocks drift in the first place

Computers do not contain perfect clocks. A system normally maintains time using a hardware oscillator and operating-system timekeeping mechanisms. The oscillator can run slightly faster or slower than an ideal reference. That difference accumulates.

For example, imagine two computers:

• Computer A’s clock gains a small amount of time each day.
• Computer B’s clock loses a small amount.
• Neither computer is synchronised to an external reference.

Initially, their clocks might differ by only a fraction of a second. After enough time, the difference can become much larger. Temperature, hardware characteristics, operating-system behaviour, and the interval between synchronisation updates can all affect clock accuracy. NTP documentation notes that oscillator frequency can vary with environmental conditions and that network delay and operating-system latency also influence synchronisation accuracy. (NTP: Network Time Protocol)

This is why setting a clock manually once is not the same as maintaining synchronised system time.

How NTP determines whether a clock is wrong

The interesting part of NTP is that the client cannot simply assume that the time it receives from a server arrived instantaneously. Suppose a client sends an NTP request to a server.

The exchange records timing information at different points:

1. The client records when it sends the request.
2. The server records when it receives the request.
3. The server records when it sends its response.
4. The client records when the response arrives.

Using these timestamps, NTP can estimate both round-trip delay and the client’s clock offset relative to the server.

The basic challenge is that the network takes time to carry the packets. NTP therefore has to account for communication delay rather than treating the server’s timestamp as if it arrived instantly. The protocol’s calculations assume, in simplified terms, that the network delay in the two directions is sufficiently similar to estimate the clock offset. (NTP: Network Time Protocol)

That assumption is not always perfect. If traffic experiences significantly different delays in each direction, the resulting clock estimate can contain an error. This is one reason Internet-based time synchronisation has practical accuracy limits.

NTP does more than use a one-time server.

Using one server creates an obvious weakness. If that server becomes unavailable, experiences an unusual delay, or provides incorrect time, the client has less information with which to evaluate the result. NTP can instead communicate with multiple time sources. The protocol uses algorithms to evaluate available measurements and select appropriate sources rather than blindly accepting every response. RFC 5905 describes concurrent associations and algorithms intended to mitigate unreliable or misleading time sources. (RFC Editor)

This gives NTP an important property: time synchronisation is based on measurements and source selection, not simply copying one machine’s clock.

For a network administrator, that distinction matters. A reliable time architecture should not depend unnecessarily on a single external server.

What does “stratum” mean in NTP?

You may encounter the term ‘stratum’ when examining NTP configurations. Stratum describes a server’s position within the NTP synchronisation hierarchy.

A simplified example looks like this:

Reference clock → Stratum 1 → Stratum 2 → Stratum 3 → Client

A primary server directly associated with an external reference is generally considered stratum 1. A server synchronised to that server can operate at stratum 2, and so on. (RFC Editor)

However, stratum should not be interpreted as a simple “accuracy score.” A higher stratum generally represents a greater distance from the reference in the synchronisation hierarchy, but actual accuracy also depends on network delay, clock stability, implementation, and other conditions. RFC 5905 explicitly discusses synchronisation distance and the effects of network paths and clock stability. (RFC Editor)

In other words, stratum is useful for understanding the NTP hierarchy, but it is not a guarantee that a lower-numbered server will always produce a better measurement in every situation.

Why synchronised clocks matter for network logs

One of the most practical reasons to maintain accurate clocks is event correlation. Modern networks generate timestamps everywhere:

• Web servers
• Firewalls
• Routers
• Operating systems
• Authentication systems
• Databases
• Backup systems
• Monitoring tools
• Applications

When an incident occurs, administrators often need to reconstruct what happened. Suppose a user reports that an application stopped working. The administrator might compare:

1. The application’s error log.
2. The web server log.
3. The database log.
4. The firewall record.
5. The operating system event log.

If each system uses a different clock, reconstructing the sequence becomes harder. The Network Time Foundation specifically highlights synchronised time as important for comparing logs across network devices and understanding security incidents. Accurate time does not automatically make logs trustworthy, but inconsistent clocks can make otherwise useful logs much harder to interpret.

Accurate time also is relevant for security.

Time appears in many security mechanisms. Authentication systems, certificates, event records, monitoring tools, and security protocols can all depend on timestamps or time-based validity periods. For example, if a computer’s clock is substantially incorrect, an otherwise valid security credential may appear to be outside its permitted time. Time inconsistencies can also make security events harder to correlate.

There is another important distinction here:

Time synchronisation and time authentication are not the same.

Knowing that a packet came from an expected NTP server does not automatically prove that the time being supplied is correct. RFC 5905 explicitly warns that authentication does not by itself guarantee that the time is correct. (RFC Editor)

For systems where time integrity is security-sensitive, administrators therefore need to consider both synchronisation and trust in the time source.

What happens when the network is unreliable?

NTP is designed for packet-switched networks where packets can experience delay, variation, loss, or disruption. A time client does not need every packet to arrive perfectly. Instead, it repeatedly obtains timing measurements and evaluates them. This makes NTP quite different from simply asking a server for the current clock reading. Network conditions still matter, though.

A heavily congested connection can introduce variable delays. A long-distance path can introduce more propagation delay. Asymmetric routing or other differences between the forward and return paths can affect the accuracy of offset estimates. (NTP: Network Time Protocol)

This leads to an important practical rule:

NTP can compensate for ordinary network imperfections, but it cannot magically eliminate the timing uncertainty introduced by the network itself.

NTP accuracy depends on the environment.

There is no single accuracy number that applies to every NTP installation. A computer synchronised over a nearby, stable local network can behave differently from one synchronised over a congested international Internet path. RFC 5905 discusses potential accuracy ranging from tens of microseconds under favourable conditions to much larger values under less favourable conditions. The Network Time Foundation likewise notes that network delay, oscillator behaviour, and operating-system latency influence real-world accuracy. (RFC Editor)

This distinction is important when reading claims about “NTP accuracy.” A normal office computer does not need the same timing architecture as a system designed for specialised high-precision applications. The required accuracy should follow the application.

NTP versus manually setting the system clock

Manually setting a clock can correct an obvious error, but it does not solve clock drift. Consider a computer whose clock gradually loses several seconds over time. Setting it correctly today may make the timestamp accurate temporarily. After enough time, the clock can drift again.

NTP continuously monitors the relationship between the local clock and its selected time sources, allowing the system to maintain synchronisation rather than relying on occasional manual corrections. The NTP Support documentation describes this as regulating the local clock continuously. (NTP Support)

This feature is especially valuable for machines that operate unattended. A server should not require an administrator to periodically check whether its clock has wandered away from the rest of the network.

Why organisations often use internal time servers

A larger network does not necessarily need every machine to contact public time servers independently. An organisation can set up internal time servers that synchronise with trusted external or local reference sources. Other systems can then synchronise against those internal servers.

This provides several practical advantages:

• Centralised configuration
• Less dependence on external connectivity
• Easier monitoring
• Consistent internal timing
• Reduced external NTP traffic
• A clearer trust hierarchy

The exact architecture depends on the organisation’s requirements, network design, security controls, and desired accuracy. For a small home network, the operating system’s built-in time synchronisation may be entirely sufficient. A larger organisation may need a deliberately designed hierarchy of internal time sources.

NTP security deserves separate attention.

Because time can influence authentication, logging, and other security functions, NTP itself can become a security consideration. The protocol has mechanisms for authenticating time information, and newer standards include Network Time Security (NTS). RFC 8915 defines NTS as a security mechanism for NTP that provides cryptographic protection for client-server time synchronisation. (NTP: Network Time Protocol)

This does not mean every computer needs a complicated custom NTP security deployment. It does mean that administrators should avoid treating time synchronisation as an unimportant background service, especially when accurate time is part of the security architecture.

At a minimum, an organisation should know:

• Which systems provide time.
• Which systems consume it.
• Which sources are trusted.
• What happens if a time source becomes unavailable.
• Whether security-sensitive systems require stronger time-source protection.

A practical way to think about network time

Imagine a group of people working together, but each person wearing a watch that slowly gains or loses time. At first, the differences are barely noticeable. Eventually, someone says an event happened at 2:15, another says it happened at 2:18, and a third says it happened at 2:11. The people may all be recording events correctly according to their own watches. The problem is that the watches do not share a reliable reference.

NTP provides a mechanism for bringing those clocks into much closer agreement. That is why time synchronisation is not merely about making the clock on your desktop display the correct hour. It creates a common temporal reference that networked systems can use when recording, comparing, and coordinating events.

What to check when network clocks disagree

If computers on the same network show noticeably different times, the problem is worth investigating rather than simply correcting each machine manually.

Check:

• Whether the systems are configured to synchronise automatically.
• Which NTP or time source each system is using.
• Whether the configured server is reachable.
• Whether synchronisation is currently successful.
• Whether the local clock is drifting unusually quickly.
• Whether firewall rules or network policies are interfering with NTP traffic.
• Whether different systems are intentionally using different time sources.
• Whether the problem is limited to display time or also affects system timestamps.

On managed networks, also check the organisation’s intended time hierarchy before changing individual machines. Correcting one device manually can conceal the underlying synchronisation problem.

The larger lesson behind NTP

Network Time Protocol solves a deceptively difficult problem: how can machines that have imperfect clocks and communicate over an imperfect network maintain a sufficiently consistent view of time?

It does this through repeated measurements, clock-offset estimation, source selection, filtering, and clock discipline rather than simply copying a timestamp from one machine to another. (RFC Editor)

For everyday computing, accurate time helps keep logs understandable and systems coordinated. For larger networks, it becomes part of the infrastructure supporting monitoring, troubleshooting, authentication, security investigations, and distributed operations. The practical takeaway is simple: if machines need to work together, their clocks need a common reference. NTP provides one of the fundamental mechanisms for maintaining that shared sense of time.