clock problem

[Ian Smith]

On Fri, 11 May 2007, M. Warner Losh wrote:

 > : Yes, but Martin already showed it was using the i8254, not TSC; would
 > : you expect the same effect using powerd with the i8254 clock?  It seems
 > : so, unless it's some problem with est and/or p4tcc under APM (canoworms)
 > 
 > No.  I would not have expected it at all.  I would have expected the
 > i8254 to not be able to provide time much better than a microsecond or
 > two, but I'd expect time to be relatively stable, modulo the normal
 > walking due to thermal variation you'd see given the relatively low
 > quality oscillators that feed it.  However, see below.

Ok, thanks for that.  Matt's post on the various clocks was handy too.

 > The i8254 time counter has a frequency of about 1.19 MHz, but it wraps
 > about 18 times a second (or once every ~55ms).  I think that if the
 > clock speed was slow enough, there might be situations where
 > interrupts are disabled long enough to blow past that 55ms mark,
 > especially on a 300MHz laptop that might be running at a very slow
 > clock rate when idle.  If it misses the wrap, then you'll see time
 > slip away.

Could well explain Martin's problem; his T42p goes right down to 75MHz
(at HZ=1000, if that's relevant) 

 | dev.cpu.0.freq: 1400
 | dev.cpu.0.freq_levels: 1400/-1 1225/-1 1200/-1 1050/-1 1000/-1 875/-1
 | 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1

 > Maybe you can experiment with the lower bounds the frequency of the
 > system can run and keep accurate time.  debug.cpufreq.verbose=1 might
 > be helpful.  You can override the lowest setting of powerd by using 
 > the sysctl debug.cpufreq.lowest.

Where might I peek to see how/where setting that sysctl acts to modify
the dev.cpu.0.freq_levels MIB, since powerd.c just eats what it's fed?
</just_curious>

TIA, Ian