[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52850FEC.2040106@redhat.com>
Date: Thu, 14 Nov 2013 13:01:16 -0500
From: Rik van Riel <riel@...hat.com>
To: Miroslav Lichvar <mlichvar@...hat.com>
CC: John Stultz <john.stultz@...aro.org>, linux-kernel@...r.kernel.org,
Prarit Bhargava <prarit@...hat.com>,
Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH RFC] timekeeping: Fix clock stability with nohz
On 11/14/2013 09:50 AM, Miroslav Lichvar wrote:
> Since commit 5eb6d205 the system clock is kept separately from NTP time
> and it is synchronized by adjusting its multiplier in a feedback loop.
> This works well when the updates are done regularly. With nohz and idle
> system, however, the loop becomes unstable at a certain update interval.
> The loop overcorrects and the frequency doesn't settle down. The clock
> has a large error, which seems to grow quadratically with update
> interval.
> In a simulation with 1GHz TSC clock and 10Hz clock update the maximum
> error went down from 4.7 microseconds to 5.5 nanoseconds. With 1Hz
> update the maximum error went down from 480 microseconds to 55
> nanoseconds.
>
> In a real test on idle machine comparing raw TSC and clock_gettime()
> time stamps, the maximum error went down from microseconds to tens of
> nanoseconds. A test with clock synchronized to a PTP hardware clock by
> phc2sys from linuxptp now shows no difference when running with nohz
> enabled and disabled, the clock seems to be stable to few tens of
> nanoseconds.
Looks like a big improvement to me.
Also very useful for virtual machines, which have no
good control over when the timekeeping routines will
run, but which can see what time it is when they do
run...
> Signed-off-by: Miroslav Lichvar <mlichvar@...hat.com>
Acked-by: Rik van Riel <riel@...hat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists