Re: System time drifts when processor idle.

[john stultz <johnstul@us.ibm.com>]

On Fri, 2010-08-27 at 17:10 -0700, Venkatesh Pallipadi wrote:
> On Fri, Aug 27, 2010 at 11:11 AM, john stultz <johnstul@us.ibm.com> wrote:
> > On Fri, 2010-08-27 at 16:12 +0200, jean-philippe francois wrote:
> >> My Timekeeping bug is still present, here is an updated script and log.
> >> I am willing to make test, but I don't know what kind of debugging
> >> info is needed.
> >>
> >> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> >> hpet acpi_pm
> >> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> >> hpet
> >
> > Huh. hpet was not what I would have expected.
> >
> >
> > So first, two experiments:
> >
> > 1) Does booting with "clock=acpi_pm" cause the issue to disappear?
> >
> > 2) Does booting with "nohz=off" cause the issue to disappear?
> >
> >
> > Venkatesh: You have any experience with HPETs that halt in idle?
> >
> 
> No. Haven't seen anything like this before with HPET.
> 
> The jump was
> 
> system | hardware(RTC)
> 15:48:43 | ven. 27 août 2010 15:48:44 CEST  -0.985908 secondes
> 15:49:04 | ven. 27 août 2010 15:54:04 CEST  -0.032800 secondes
> 
> We lost ~300 seconds and from dmesg
> hpet0: 3 comparators, 64-bit 14.318180 MHz counter
> 
> Which is close to 2^32 HPET ticks. So, looks like we have some 32 bit
> wraparound somewhere..

Huh. So you're thinking the timer tick scheduler is pushing way past the
HPET wrap length, and then we're missing an accumulation point and
things wrap under us? 

We have some code to try to limit the nohz length to avoid hardware
wrapping, but honestly I'd be surprised if the system is actually that
idle for that long (no timers firing for 5 minutes? that'd be really
impressive!).

jean-philippe: Is the drift always in 5 minute increments? Can you leave
it idle for 3 minutes and see a similar 3 minute delay, or is it always
in units of 5 ?

thanks
-john