On Wed, Sep 16, 2026 at 6:52 PM Eva Kurchatova <[email protected]> wrote: > > raw_skew measures the drift between CLOCK_MONOTONIC and > CLOCK_MONOTONIC_RAW and compares it against the adjustment adjtimex() > reports, but for the latter it reads only tx.freq. The kernel takes > the tick value into the adjustment as well, worth a microsecond of the > tick length per unit, a hundred ppm each, and a time synchronisation > daemon does put the coarse part of its correction there. Where it > does, the two numbers cannot meet: > > # Estimating clock drift: -51.724(est) 48.277(act) [FAILED] > > On the machine measured, chronyd held freq at 48.278 ppm with tick at > 9999, so the correction really applied is -51.722 ppm, which is what > the clocks show. The skip for an externally adjusted clock does not > catch this: the clock is steady, the offset is zero, and neither freq > nor tick moves during the run. > > Count what tick is worth alongside freq. On the same machine: > > # Estimating clock drift: -51.724(est) -51.723(act) [OK] > > Signed-off-by: Eva Kurchatova <[email protected]>
I've not closely reviewed the math, but it looks roughly ok to me. I was going to object that I thought we nulled out the other adjtime values before testing, but I must be recalling a different test (adjtick.c I think). Acked-by: John Stultz <[email protected]> Thanks for fixing this! -john
