Re: PIT, TSC and power management [was: Re: 2.6.0-test3 "loosing ticks"]

[john stultz <johnstul@us.ibm.com>]

On Thu, 2003-08-14 at 17:19, Charles Lepple wrote:
> I also see the time offset problem (Athlon MP 2000+ x2, Tyan S2460 m/b, 
> 2.6.0-test{1,2,3}) but it is most noticeable when I have amd76x_pm 
> installed (it's not in 2.6.x yet, but a late 2.5.x patch was posted to 
> LKML a little while back).
> 
> amd76x_pm is roughly equivalent to ACPI C2 idling, but since my BIOS 
> doesn't export any C-state functionality to the kernel ACPI code, I am 
> stuck with letting amd76x_pm frob the chipset registers. A quick look at 
> AMD's datasheets does not indicate that a return from C2 should cause 
> much delay at all-- if I understand the timing requirements correctly, 
> it would have to sit for more than 1 ms to miss more than one interrupt. 
> That said, I don't see any missing interrupts indicated in 
> /proc/interrupts, nor do any such messages appear in the kernel logs.

In this case you're throttling the cpu frequency. This affects the
frequency the TSC updates, which makes it very hard to use the TSC as a
timesource (the cpu_freq notifier tries to compensate by changing the
tsc multiplier but my systems don't have cpu_freq drivers, so I've not
seen it work). 

> Brings up another question: does the "try HZ=100" suggestion still apply 
> for these faster machines? I would think that if HZ=1000 is too fast, 
> then at least an occasional lost interrupt would be logged.

If you're losing interrupts and the lost-tick detection code is not
compensating, shifting back to HZ=100 just tries to minimize the
problem. 

 
> When using the TSC for time-of-day, I generally have to set tick to 
> 10200 or somewhere thereabouts. ntpd usually gives up after a few hours, 
> though, so I presume that this value for tick is only good for a certain 
> combination of processor load and planetary alignment.
> 
> I booted with clock=pit to test that, and now I need tick=9963 
> (according to adjtimex's configuration routine). However, that makes the 
> clock jump all over the place, with ntpd making step adjustments +/- 2 
> seconds every 5 minutes.
> 
> > Approximately at what rate does it skew?
> 
> Well, it's not constant, and I don't trust the tick values given above, 
> since they don't seem to hold true for long.


Do these problems still show when you're not using the amd76x_pm?


> > Does ntpdate -b <server> set it properly?
> 
> I'm confused. Are there cases where a step time adjustment would fail? 
> Is there a possibility that the kernel is rejecting ntpd's step 
> adjustments? (I presume that these use the same as 'ntpdate -b'; 
> specifically, the time is not slewed.)

Well, depending on how ntp is compiled, it could use stime, rather then
settimeofday. This causes ntp to set the time on average .5 seconds off
the desired time. Since .5 is outside the .128 sec slew boundary, ntp 
will do another step adjustment which has the same poor accuracy. This
results in ntp just hopping back and forth around the desired time. 

thanks
-john