lkml.org 
[lkml]   [2009]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Linux 2.6.29-rc6
    From
    Date
    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




    \
     
     \ /
      Last update: 2009-03-04 20:01    [W:3.003 / U:0.136 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site