selftests: timers: Count what tick is worth in the drift estimate

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@virtuozzo.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Acked-by: John Stultz <jstultz@google.com>
Link: https://patch.msgid.link/20260917015237.2462954-1-eva.kurchatova@virtuozzo.com

0 files changed, 0 insertions, 0 deletions