How does NTP actually keep clocks accurate?

The basic exchange uses four timestamps: when the client sends a request, when the server receives it, when the server sends its response, and when the client receives that response. From those, the client estimates the round-trip network delay and its clock offset from the server.

The catch is that it cannot directly measure the one-way delays without already having synchronized clocks. The offset estimate assumes the request and response paths have roughly equal delays. If one direction is consistently slower, that asymmetry introduces error. Variable latency and congestion add noise too, so a single exchange is not a reliable answer.

NTP takes repeated samples and filters them. Lower-delay samples are generally more useful because they tend to have spent less time waiting in queues, though even a low-delay path can be asymmetric.

NTP doesn't just set the clock once and call it done. A client keeps measuring its offset and adjusts the local clock, including its rate, to compensate for drift. Small corrections are often applied gradually so the clock doesn't keep jumping around.

When a source disappears, the local clock keeps running. Its estimated rate correction can help for a while, but uncertainty grows the longer it goes without a usable reference. A large initial error may instead need a clock step, depending on the implementation and configuration.

Think of it as a network of time sources, not necessarily one master. Servers can get time from reference clocks or from other NTP servers, and clients can compare multiple sources. Selection algorithms try to reject inconsistent sources and use the remaining measurements to improve the estimate.

Stratum describes distance in the synchronization hierarchy. It is useful context, but a lower stratum number alone does not guarantee a more accurate time at your client. The source quality and network path still matter.

One small correction to the premise: NTP itself doesn't require an atomic clock. It distributes and estimates time from whatever references the servers use. Some ultimately trace back to atomic clocks, while others use different references.

The quality of that reference matters. NTP can keep clients close to a server's clock, but that doesn't magically make the server's clock correct.

If you need tighter synchronization, look at PTP too. It is a different protocol and can benefit from local network support and hardware timestamping. Simply switching protocols won't guarantee better accuracy if the network and equipment aren't set up for it.