Messages in this thread | | | From | Jonathan Woithe <> | Subject | Re: 2.6.14-rt21: slow-running clock | Date | Thu, 8 Dec 2005 14:41:10 +1030 (CST) |
| |
> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |