Re: 2.6.14-rt21: slow-running clock

[Jonathan Woithe <jwoithe@physics.adelaide.edu.au>]

> On Thu, 2005-12-08 at 13:32 +1030, Jonathan Woithe wrote:
> > > > I'm also wondering whether this might be related to one other thing I
> > > > noticed a week or so back (also reported to the list, but thus far no
> > > > followups). If I enabled the (new) "High resolution timers" feature (as
> > > > distinct from HPET), things like /usr/bin/sleep run for far longer than
> > > > they should irrespective of machine load.  For example, "sleep 1" from bash
> > > > actually delays 38 seconds, not 1 second as expected.
> > > 
> > > Does disabling the "High resolution timers" feature change the behavior
> > > all?
> > 
> > I should clarify.  Everything I've given you thus far has been with the
> > "high resolution timers" feature disabled.  Two or so weeks ago I tried
> > enabling it and that's when "sleep 1" took 38 seconds to complete. 
> > Disabling "high resoltion timers" at least made "sleep 1" behave somewhat
> > saner.  I don't know if having the high res timers enabled affects the
> > accuracy of the system clock however.  I'll test this tonight.
> 
> Ok. I think I've reproduced the issue on my laptop as well. It seems to
> be a -rt issue only (I need to go back and test HRT too) as I do not see
> the problem w/ my B13 patchset. 
> 
> Possibly we are getting preempted before entering or exiting C3 mode?
> I'll need to look further. It isn't directly related to cpu load or
> idleness (a cpu pegged box doesn't drift that badly), but it might be
> io-related. 

Being IO-related is believable based on what I've seen.  In the fault
condition, the system clock averages 5 seconds behind the CMOS clock
immediately after the system has booted (which requires a large amount of
IO).  If the system sits idle not doing anything the drift is almost
non-existant.  Jackd is really good at slowing the system clock down though,
but then again jackd is doing a lot of IO.

All this seems to confirm earlier idea that there are two issues: a slowdown
in the c3tsc timer, and something in RT which causes the selection of the
c3tsc timer ahead of the acpi_pm timer.

Regards
  jonathan