Re: [PATCH RFC] timekeeping: Fix clock stability with nohz

[Miroslav Lichvar <mlichvar@redhat.com>]

On Mon, Nov 18, 2013 at 01:28:07PM -0800, John Stultz wrote:
> Also is this brokenness something that has been around for awhile for
> you or more recently cropped up?  I'm wondering as nohz idle has been
> around for quite a few years and I've not seen too many complaints. So
> I'm wondering if I'm looking in the right places, or if something has
> regressed recently, or if its just that accuracy expectations have gone up?

I think the problem was there right from the beginning when the
internal synchronization loop was introduced, but before PTP hardware
clocks there might not had been a reference which could be used to
evaluate the stability of the system clock at this level. The quantum
mechanical property of the problem that it disappears when you
increase sampling doesn't help much either :).

IIRC the first time I noticed something wasn't quite alright was in
2009 when I wrote a PPS refclock driver for chrony. With a GPS
receiver connected to serial port the synchronization seemed to work
better when the system was loaded. My explanation at the time was that
it's a HW limitation, the interrupt latency/jitter is worse when the
CPU is idle. I had no idea there could be a problem in the kernel
timekeeping.

-- 
Miroslav Lichvar