lkml.org 
[lkml]   [2009]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux 2.6.29-rc6


    On Sun, 15 Mar 2009, Jesper Krogh wrote:
    > > >
    > > > [ 0.000000] Fast TSC delta=34227730, error=6223+6219=12442
    > > > [ 0.000000] Fast TSC calibration using PIT
    > > > [ 0.000000] Detected 2312.045 MHz processor.
    >
    > My conclusion was that I would get a time reset after some time since the
    > offset just increased as time went by (being reasonably small at the
    > beginning).
    >
    > I had it up for around 30 minutes... Should I have tested longer?

    It would be good to test longer. Your previous emails showed:

    2.6.26: time.c: Detected 2311.847 MHz processor.
    2.6.29: Detected 2310.029 MHz processor.

    where that first one was a successful boot, and the second one was a
    failing one. So let's assume that 2311.847 is the "correct" frequency.

    The difference between the correct one and your failing one is ~790 ppm,
    which is above the 500ppm ntpd threshhold. And as we saw earlier, those
    differences were pretty consistent, ie in your list of four successive
    boots, the old code consistently gave a frequency error that was roughly
    .7 permille off (ie exactly that 700 ppm).

    HOWEVER! With that patch you just tried, you got

    Detected 2312.045 MHz processor.

    and the difference between _that_ and the assumed-correct-one is actually
    just 85 ppm. Which should be perfectly fine.

    [ With the "test against PM timer, you had:

    [ 0.000000] ref_freq: 2311825 pit_freq: 2310386
    [ 0.000000] ref_freq: 2311803 pit_freq: 2310190
    [ 0.000000] ref_freq: 2311824 pit_freq: 2310080
    [ 0.000000] ref_freq: 2311831 pit_freq: 2310130

    on four boots, so averaging them gives 2311.82 Mhz, and the 2312.045MHz
    you got with the improved fast-PIT code is still _way_ below 500ppm from
    that - it's ~95 ppm away.

    IOW, the new frequency realy looks likely to work. ]

    Quite frankly, we don't know how exact the PM-timer is either - we just
    know that the detection is "stable" (but so was the old PIT timer
    detection: it was stably at 700ppm lower from the PM timer. So there is
    nothing that says that 2311.82Mhz is the "correct" frequency, but we
    obviously know from your ntpd saga that it is much closer to correct than
    the old 2310.029 was.

    End result of all this: I'd really like you to try the modified PIT
    frequency code for longer. Also, remember that getting one (or a couple)
    "time reset" messages from ntpd while it's trying to sync up is not a
    problem per se - it can validly take a while to synchronize. The problem
    is literally only if it doesn't synchonize over time at all.

    Linus


    \
     
     \ /
      Last update: 2009-03-15 20:07    [W:0.022 / U:33.244 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site