Re: Linux 2.6.29-rc6

[John Stultz <johnstul@us.ibm.com>]

On Wed, 2009-03-04 at 19:36 +0100, Jesper Krogh wrote:
> Jesper Krogh wrote:
> > john stultz wrote:
> >> I guess something to test my idea above (that the drift is bad enough
> >> that NTPd isn't making slew adjustments via adjtimex offset) is to
> >> remove NTPd from the init.d startup.
> >>
> >> Then after rebooting (into 2.6.29), run the attached python script for
> >> 10 minutes or so to get an idea of the ppm drift. Then repeat with
> >> 2.6.26.
> >>
> >> To run: ./drift-test.py <ntp server>
> >>
> >> It will give some wild ppm numbers, but after a few minutes it should
> >> settle down to the "natural drift" of the system.
> > 
> > Ok. I removed ntpd from the system... heres is from "non-working 
> 
> Updated. I think I has NTPd running in the former "non-working" test. I 
> just tried to reproduce the numbers, and they look like this 
> (reproducible on 2.6.29-rc6).

Yea, the last numbers did look odd :)

> jk@quad12:~$ python drift-test.py 10.192.96.19
> 04 Mar 19:27:10         offset: -0.157696       drift: -693.0 ppm
> 04 Mar 19:28:10         offset: -0.195134       drift: -625.098360656 ppm
> 04 Mar 19:29:10         offset: -0.232579       drift: -624.595041322 ppm
> 04 Mar 19:30:10         offset: -0.270021       drift: -624.408839779 ppm
> 04 Mar 19:31:11         offset: -0.307461       drift: -621.727272727 ppm
> 04 Mar 19:32:11         offset: -0.344903       drift: -622.185430464 ppm
> 04 Mar 19:33:11         offset: -0.382345       drift: -622.491712707 ppm
> 04 Mar 19:34:11         offset: -0.419794       drift: -622.727488152 ppm
> 04 Mar 19:35:11         offset: -0.457239       drift: -622.89626556 ppm


Yea, so from this and the settled ntpdc -c kerninfo data before, we can
see that the drift is further out then the 500ppm NTP can handle.

So with that at least confirmed, we can focus back on to the fast-pit
tsc calibration code.

Ingo, Thomas: I'm missing a bit of the context to that patch, other then
just speeding up boot times, was there other rational for moving away
from the ACPI PM timer based calibration?

Could we maybe add a quick test that the pit reads actually take the
assumed 2us max? Doing this maybe via the HPET/ACPI PM?

thanks
-john