A server can receive an honest timestamp and still set its clock badly: the reply spent time traveling across the network. Even after an accurate correction, the machine can start drifting again. Understanding chrony means following how it separates measurement, estimation, and correction—and why each stage leaves something for the next one to do.[1][2]

The background process, chronyd, can synchronize a computer from network time servers or an attached reference clock, and can serve time to other computers. Its companion, chronyc, exposes what the daemon believes and what it is doing. This account uses the version 4.7 manuals as a fixed reference.[1][4]

A packet brings four timestamps

In a basic Network Time Protocol exchange, the client records when it sends a request and receives the reply. The server supplies when it received that request and sent its response. These four readings let the client subtract the server's processing interval from the total elapsed time, producing a round-trip network delay. They also provide an estimate of the difference between the two clocks.[2]

The catch is the journey in each direction. Consider a simplified example with perfect timestamps and two clocks already in agreement. If the request takes 2 milliseconds to reach the server and the response takes 8 milliseconds to return, the usual NTP calculation estimates the server to be 3 milliseconds behind the client. That is half the difference between the two travel times. This is an illustration calculated from the protocol's equation, not a measured chrony result: an uneven path can look like a wrong clock.[2]

chrony therefore evaluates delay as well as offset. It weights measurements and can reject unusually delayed replies; maxdelay provides an explicit round-trip ceiling.[3] A late reply is evidence to assess before it becomes a clock correction.

Learning the clock between replies

Repeated measurements reveal something a single exchange cannot: whether the clock is steadily gaining or losing time. In chronyc sourcestats -v, NP counts retained samples and Span describes the period they cover. chrony fits a line through those samples to estimate offset and drift. When the fit deteriorates, it can discard older samples and fit again.[4]

An illustrative oscillator error of 20 parts per million accumulates 72 milliseconds in an hour: 20 millionths multiplied by 3,600 seconds. Correcting yesterday's offset leaves that rate error waiting to produce tomorrow's discrepancy. Learning the rate gives the daemon a way to compensate between measurements.

The driftfile directive preserves an estimated rate and its uncertainty across restarts. That gives the next run a starting estimate before enough fresh observations arrive.[3] The project's FAQ also discourages periodically running the one-shot chronyd -q command as a substitute for the persistent daemon: that approach steps time and does not correct the clock's frequency.[5]

Several sources provide another kind of evidence. The FAQ recommends at least three or four suitable servers so chrony can identify false time and combine measurements.[5] More replies from one server improve the history of that relationship; observations from other servers allow disagreement to become visible.

Knowing the time and showing the time

There is a revealing distinction inside chronyc tracking: chronyd maintains a software NTP clock, while the system clock follows it. The System time field reports the remaining difference between them. A daemon can have a good estimate while the clock read by applications is still catching up.[4]

The normal correction is a slew: temporarily change how fast the system clock advances. A step changes its reading immediately. An illustrative configuration excerpt makes the policy concrete:

makestep 1.0 3

This permits a step for an error greater than one second during the first three clock updates after chronyd starts. The limit counts updates, not seconds. Restarting the daemon begins that allowance again, so it needs to fit the application's tolerance for jumps.[3]

This is an operational choice with consequences. A gradual correction leaves a period of residual error; an immediate correction introduces a discontinuity. For a small operations team, deciding when dependent services may start is more useful than copying a step threshold without understanding when it applies.

chronyc waitsync 60 0.01 can wait up to roughly ten minutes for synchronization and for the remaining correction to fall below 10 milliseconds. Its success is a check on chrony's reported state, not an external certificate of absolute accuracy.[4]

The measurement still needs a witness

Facebook's engineers made that distinction tangible in their March 2020 account of testing chrony. They compared daemon estimates with physical pulse measurements and an external laboratory instrument. The results showed why a very small reported offset could coexist with substantially larger measured error. They also tested hardware timestamping, which moves packet timing closer to the network interface. Those were results from their controlled data-center setup, not a performance promise for every network.[6]

For a team diagnosing ordinary server timestamps, the immediate questions are whether usable sources agree, whether the rate estimate has settled, and how much correction remains. A team promising tight bounds for experiments or distributed infrastructure needs additional measurement expertise and a way to test those bounds independently. The required assurance grows with the consequence of being wrong.

Independent attention to chrony has also examined a different dimension: LWN's October 2017 coverage of NTP security audits relayed the reviewers' favorable assessment of its focused feature set.[7] That historical assessment concerns software security; it does not establish the accuracy of a particular installation.

The architecture is useful precisely because its stages remain inspectable. A delayed packet, an unstable rate estimate, and a system clock still being corrected call for different investigations. Reading them separately turns “the clock is wrong” into a problem an operator can locate.

Sources

1. chrony project, chronyd(8), version 4.7 — daemon responsibilities and operating modes.
2. David Mills and colleagues, RFC 5905, June 2010, section 8 — NTP timestamp exchange, offset, and round-trip delay equations.
3. chrony project, chrony.conf(5), version 4.7 — measurement delay, driftfile, and makestep configuration.
4. chrony project, chronyc(1), version 4.7 — sourcestats, tracking, the software NTP clock, and waitsync.
5. chrony project, Frequently Asked Questions — sections 2.7 and 2.8 on source selection and one-shot synchronization; checked October 7, 2026.
6. Oleg Obleukhov, “NTP: Building a more accurate time service at Facebook scale,” March 18, 2020 — independent physical measurements and hardware timestamping experiments.
7. Jonathan Corbet, “A security review of three NTP implementations,” LWN, October 1, 2017 — independent contemporary coverage of the security review.
8. NIST, “F2 Atomic Clock,” April 3, 2014, reference 14PML013 — photograph of Steve Jefferts and Tom Heavner with NIST-F2; image credit NIST.