Re: 2.6.14-rt21: slow-running clock

From: Jonathan Woithe
Date: Wed Dec 07 2005 - 23:14:59 EST


> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/