Re: [PATCH 1/2] selftests: timers: count what tick is worth in the drift estimate

[John Stultz]

On Wed, Sep 16, 2026 at 6:52 PM Eva Kurchatova
<eva.kurchatova@xxxxxxxxxxxxx> 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 <eva.kurchatova@xxxxxxxxxxxxx>

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 <jstultz@xxxxxxxxxx>

Thanks for fixing this!
-john