[tip: timers/core] selftests: timers: Count what tick is worth in the drift estimate

["tip-bot2 for Eva Kurchatova" <tip-bot2@linutronix.de>]

The following commit has been merged into the timers/core branch of tip:

Commit-ID:     a252cb93e1568d9f0754b9b2ac4829d896daa14e
Gitweb:        https://git.kernel.org/tip/a252cb93e1568d9f0754b9b2ac4829d896daa14e
Author:        Eva Kurchatova <eva.kurchatova@virtuozzo.com>
AuthorDate:    Thu, 17 Sep 2026 04:52:31 +03:00
Committer:     Thomas Gleixner <tglx@kernel.org>
CommitterDate: Tue, 29 Sep 2026 22:03:31 +02:00

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
---
 tools/testing/selftests/timers/raw_skew.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/tools/testing/selftests/timers/raw_skew.c b/tools/testing/selftests/timers/raw_skew.c
index 0c87a8f..dfca3e2 100644
--- a/tools/testing/selftests/timers/raw_skew.c
+++ b/tools/testing/selftests/timers/raw_skew.c
@@ -91,6 +91,7 @@ int main(int argc, char **argv)
 {
 	struct timespec mon, raw, start, end;
 	long long delta1, delta2, interval, eppm, ppm;
+	long tick_nom;
 	struct timex tx1, tx2;
 
 	setbuf(stdout, NULL);
@@ -129,6 +130,17 @@ int main(int argc, char **argv)
 	/* Avg the two actual freq samples adjtimex gave us */
 	ppm = (long long)(tx1.freq + tx2.freq) * 1000 / 2;
 	ppm = shift_right(ppm, 16);
+
+	/*
+	 * The tick value holds the coarse part of the adjustment, a
+	 * microsecond of the tick length per unit, and time sync daemons
+	 * do put part of their correction there. What it is worth has to
+	 * be counted in as well, or a clock disciplined through it looks
+	 * off by a hundred ppm a unit against what the two clocks show.
+	 */
+	tick_nom = USEC_PER_SEC / sysconf(_SC_CLK_TCK);
+	ppm += (long long)(tx1.tick + tx2.tick - 2 * tick_nom) *
+	       (USEC_PER_SEC / tick_nom) * 1000 / 2;
 	printf(" %lld.%i(act)", ppm/1000, abs((int)(ppm%1000)));
 
 	if (llabs(eppm - ppm) > 1000) {