Re: [PATCH] timekeeping: Fix 1ns/tick drift with GENERIC_TIME_VSYSCALL_OLD

From: Thomas Graziadei
Date: Wed Jun 01 2016 - 08:00:31 EST

On 06/01/2016 01:11 AM, John Stultz wrote:
On Tue, May 31, 2016 at 6:06 AM, Thomas Graziadei
<thomas.graziadei@xxxxxxxxxxxxxxxxx> wrote:
From: Thomas Graziadei <thomas.graziadei@xxxxxxxxxxxxxxxxx>

The user notices the problem in a raw and real time drift, calling
clock_gettime with CLOCK_REALTIME / CLOCK_MONOTONIC_RAW on a system
with no ntp correction taking place (no ntpd or ptp stuff running).

Hmm.. Curious. Was it actually drifting, or was it just
oscillating/ringing near the RAW clock's value?

It is actually drifting.

This is the output from a little test program:

realtime : 1464775074:846282133
raw time : 1054:851963700
drift_real: 999402ns

total duration: 1000s 158517540ns

The problem is, that old_vsyscall_fixup adds an extra 1ns even though
xtime_nsec is already held in full nsecs and the remainder in this
case is 0. Do the rounding up buisness only if needed.

The patch looks ok. But I'm curious what architecture you were seeing
this on (ia64, powerpc?), as it would be much nicer to have those
architectures migrate off of the old low-res vsyscall calculation and
use the newer method with sub-ns precision, instead of trying to
further fix up the deprecated method.

I had submitted a patch to convert ia64 awhile back, but I don't
recall getting much feedback.

We are using a powerpc architecture.

I guess you are right, it would be nicer to use the new method but then on the other hand, this timing topic is rather new to me.