clock too slow - big time offset with ntpdate

[Ian Smith]

On Wed, 2 May 2007, Martin Dieringer wrote:
 > On Tue, 1 May 2007, Martin Dieringer wrote:
 > 
 > > On Tue, 1 May 2007, Clayton Milos wrote:
 > >
 > >>> Hi,
 > >>> 
 > >>> I get about half a second time offsets after 10 seconds, and more
 > >>> than 100s after half an hour or so.
 > >>> I think it has to do with powerd, if I kill that, the time stays correct.
 > >>> It happens both on a Compaq nc4000 and an IBM ThinkPad T42p laptop.
 > >>> 
 > >>> Can this be solved?
 > >>> thanks
 > >>> m.
 > >> 
 > >> This has got to do with the speed stepping of the CPU to save battery.
 > >> Far as I know there's no fix yet.
 > >> 
 > >> Guys is it possible to hack powerd to change a sysctl variable when it 
 > >> changes the CPU frequency or isn't it that simple?
 > >
 > >
 > > Another effect of the problem seems to be the intermittent sound
 > > output. Playback is ok when powerd is killed.
 > > When changing freq by sysctl, I still get hickups in sound, so this
 > > would be no solution.
 > 
 > the hiccups have reappeared, so they are not related to powerd.
 > 
 > I still have 0.5 seconds time offsets after 10 minutes, on the
 > thinkpad, without powerd...

I'm wondering if this might have to do with power_profile's settings of
hw.acpi.cpu.cx_lowest when moving from AC to battery power?

If you don't specify {performance,economy}_cpu_freq="NONE" in rc.conf,
powerd and power_profile will argue the toss on every switch of line
state (running powerd -v illustrates this nicely).  powerd, however,
does not as yet affect the cx setting also.

The default values of {performance,economy}_cx_lowest are "HIGH" and
"LOW" on my 6.1-R system, but "HIGH" and "HIGH" on my 5.5-STABLE box,
though the latter isn't using ACPI; you might want to check these in
your /etc/defaults/rc.conf and override them in rc.conf if necessary. 

Anyway, this is a bit of a stab in the dark, but try setting in rc.conf
economy_cx_lowest="C2" which has the effect of having power_profile set
hw.acpi.cpu.cx_lowest="C2" on line state change rather than the "LOW"
value, probably C3, to see if this might affect your timing problem?

On my T23 on 6.1-R, I noticed that the C3 state is never used (as shown
by hw.acpi.cpu.cx_usage) unless the machine was booted up on battery :-/
I also seem to recall reading that C3 may be problematic on some boxes,
possibly related to timing problems, but like Jeremy I'm not sure where.

Cheers, Ian