Four timestamps separate clock error from travel time
A time-synchronization protocol such as Network Time Protocol (NTP) does more than ask a server what time it is. It records when a request leaves the computer, when the server receives it and replies, and when the reply returns. Those four timestamps let it estimate two different things: how long the exchange took and how far the computer’s clock is ahead of or behind the server’s.
The server’s time can be compared with the computer’s clock at both ends of the exchange. Averaging those comparisons helps cancel the time spent traveling across the network. The result is an estimate of the clock offset—the correction needed to bring the computer’s clock closer to the server’s.
The estimate depends on the route
That calculation works best when the request and reply take roughly equal time to travel. If one direction is much slower—for example, because of congestion or a different network route—the timestamps cannot reveal the imbalance exactly. The protocol may mistake some of that uneven travel time for a clock difference.
To reduce the effect of a single bad exchange, time-sync software can take measurements repeatedly and favor reliable ones. A long delay makes a sample less useful because there is more opportunity for network conditions to distort it.
Why the clock is corrected gradually
Once the computer estimates its offset, it does not always jump straight to the new time. A sudden jump could disrupt software that relies on timestamps moving forward consistently, such as logs or scheduled tasks. Instead, the clock can be adjusted gradually, speeding up or slowing down its tick until it catches up.
So a slow connection can make the time check less precise, but it does not automatically make the displayed time late by the full round-trip delay. The computer uses the timing of the exchange to distinguish the network journey from the clock error—and smooths the correction to avoid breaking time-dependent software.
