Linux NTP Kernel unsync flag remains long afterNTP&Kernel have PPL sync - NTP

This is a discussion on Linux NTP Kernel unsync flag remains long afterNTP&Kernel have PPL sync - NTP ; Steve Kostecke wrote: > On 2008-08-28, David Woolley wrote: > >> Steve Kostecke wrote: >> >>> ntpq -c"rv 0 offset" will tell you the current offset of your ntpd. >> Careful. That is "Offset", not the common sense meaning of ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 27 of 27

Thread: Linux NTP Kernel unsync flag remains long afterNTP&Kernel have PPL sync

  1. Re: Linux NTP Kernel unsync flag remains long after NTP&Kernel havePPL sync

    Steve Kostecke wrote:
    > On 2008-08-28, David Woolley wrote:
    >
    >> Steve Kostecke wrote:
    >>
    >>> ntpq -c"rv 0 offset" will tell you the current offset of your ntpd.

    >> Careful. That is "Offset", not the common sense meaning of offset,
    >> which might be put something like: the true error between the local
    >> clock and true time.

    >
    > Let's see ... there's the offsets shown with:


    I don't understand what you are demonstrating. Without a measurment of
    local clock error to a resolution of about 10 microseconds, in this
    case, you cannot compare these offsets against the actual error,
    although you can guess that the actual error might be of the order of 50
    microseconds, relative to the systematic error in your time sources,
    although one really cannot make good statistical inferences from
    essentially one measurement; I've also given Dr Mills the benefit of the
    doubt.

    >
    > ntpq -c"rv 0 offset"
    >
    > ntpq -p
    >
    > ntpdc -c kern | grep offset
    >
    > Take your pick ...
    >
    > Running all of those commands together against one of my systems
    > produces the following (I've combined the two ntpq invocations):
    >
    > $ ntpq -pc"rv 0 offset" edge_box | awk '/offset=/ { print }; \
    > /^*/ { print $1 " " $9}'; ntpdc -c kern edge_box | grep offset
    > offset=0.421
    > *ntp.cox.net 0.264
    > pll offset: 0.000407 s


    pll offset and rv offset are pretty much the same, which is what you
    would expect, as they are both averages from the same set of time
    sources. cox.net is different, although of the same order of magnitude.
    but represents the value for a single source.
    >


  2. Re: Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync


  3. Re: Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync

    I'd appreciate folks collecting various bits of wisdom about the
    synchronization status of ntpd at:

    http://support.ntp.org/bin/view/Dev/NtpdsSyncStatus

    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  4. Re: Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync

    Hello Steve,

    On Friday, August 29, 2008 at 17:53:30 +0000, Steve Kostecke wrote:

    > Why does any of this matter when you have NTP to set the clock at
    > start up?


    For 3 main reasons:

    -1) hwclock can set the system clock much earlier in the boot sequence
    than ntpd.

    -2) ntpd sometimes cannot set the clock at startup. Maybe the ADSL line
    is temporarily down, the GPS satellites out of view, or the master
    server stopped for maintenance.

    -3) The startup behaviour of ntpd is cleaner when the system clock was
    already close. And ntpd -gq slews faster a small initial offset than
    a large one.

    hwclock --hctosys can be one of the first actions performed by init.
    When it is well calibrated, hwclock can set the clock right to some
    milliseconds. Then ntpd can quickly slew those few milliseconds
    towards perfection. Ntpd practically never has to step the clock.

    Hwclock also makes possible some ntpd usage scenarios. Like for example
    ntpd syncing on a PPS-only refclock, without other means to number the
    pulses than the system clock itself.

    All this is possible when hwclock is well used. The problem is that many
    distros use hwclock very suboptimally, calibrate drift wrongly, use the
    util-linux fork instead of the real thing, call hwclock twice at startup
    (just to waste precious time??), or leave eleven-minutes mode enabled.
    This braindamage cannot give good results, and leads many people to
    wrongly think that an RTC can't be better than the second. When one
    should be able to expect some hundreds of microseconds after a reboot,
    and some units of milliseconds after a night powered-off.


    Serge.
    --
    Serge point Bets arobase laposte point net

  5. Re: Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync

    Serge Bets writes:

    >Hello Steve,


    > On Friday, August 29, 2008 at 17:53:30 +0000, Steve Kostecke wrote:


    >> Why does any of this matter when you have NTP to set the clock at
    >> start up?


    >For 3 main reasons:


    > -1) hwclock can set the system clock much earlier in the boot sequence
    >than ntpd.


    > -2) ntpd sometimes cannot set the clock at startup. Maybe the ADSL line
    >is temporarily down, the GPS satellites out of view, or the master
    >server stopped for maintenance.


    > -3) The startup behaviour of ntpd is cleaner when the system clock was
    >already close. And ntpd -gq slews faster a small initial offset than
    >a large one.


    >hwclock --hctosys can be one of the first actions performed by init.
    >When it is well calibrated, hwclock can set the clock right to some
    >milliseconds. Then ntpd can quickly slew those few milliseconds
    >towards perfection. Ntpd practically never has to step the clock.


    >Hwclock also makes possible some ntpd usage scenarios. Like for example
    >ntpd syncing on a PPS-only refclock, without other means to number the
    >pulses than the system clock itself.


    >All this is possible when hwclock is well used. The problem is that many
    >distros use hwclock very suboptimally, calibrate drift wrongly, use the
    >util-linux fork instead of the real thing, call hwclock twice at startup
    >(just to waste precious time??), or leave eleven-minutes mode enabled.
    >This braindamage cannot give good results, and leads many people to
    >wrongly think that an RTC can't be better than the second. When one
    >should be able to expect some hundreds of microseconds after a reboot,
    >and some units of milliseconds after a night powered-off.


    As you know, linux's use of the hwclock/rtc is now seriously damaged with the
    hpet stuff. The stadards, probably set by MS, are that when hpet is
    enabled, all the interrupts from the rtc are hjacked and never delivered to
    the system as rtc interrupts. The Linux munge is to more or less do a poll
    with a 16ms ( not microsec) quantization. hwclock can apparently get around
    this using the directisa option by polling the rtc ( using up immense
    computer resources for a second or two). It is a totally rediculous
    harware decision by Intel.

    (And yes, Mandriva uses the util-linux version)

    Why does Brian not get his version back into util-linux?



  6. Re: Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync

    Hello Bill,

    On Saturday, August 30, 2008 at 16:54:47 +0000, Unruh wrote:

    > when hpet is enabled, all the interrupts from the rtc are hjacked and
    > never delivered to the system as rtc interrupts.


    Exact. The nice dreams above about the mythical RTC microsecond are
    totally annihilated by the HPET problem. Solutions today are only nohpet
    or --directisa. However it appears that, following your bug report,
    David Brownell is now exploring a new workaround for future kernels.
    IIUC he managed to convince ACPI to intercept RTC interrupts and to
    forward them to the CPU. I could not test the patch, and know nothing
    about ACPI. But this looks quite promising.


    > And yes, Mandriva uses the util-linux version


    So do the current and the (now frozen) future Debians, and so does
    Ubuntu. They also call hwclock --hctosys *twice* at startup (!?).
    They evaluate the drift rate from shutdown to shutdown, thus including
    uptime. And they don't correct drift at all.

    At the morning startup, those distros would give me an initial offset of
    maybe 5 plain seconds, instead of the 5 milliseconds or better I get
    routinely from hwclock 2.33


    > Why does Brian not get his version back into util-linux?


    To me, hwclock seems to be much better standalone than in a collection
    of unrelated utilities. Active development vs. careless stagnation.


    Serge.
    --
    Serge point Bets arobase laposte point net

  7. Re: Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync

    Serge Bets writes:

    >Hello Bill,


    > On Saturday, August 30, 2008 at 16:54:47 +0000, Unruh wrote:


    >> when hpet is enabled, all the interrupts from the rtc are hjacked and
    >> never delivered to the system as rtc interrupts.


    >Exact. The nice dreams above about the mythical RTC microsecond are
    >totally annihilated by the HPET problem. Solutions today are only nohpet
    >or --directisa. However it appears that, following your bug report,
    >David Brownell is now exploring a new workaround for future kernels.
    >IIUC he managed to convince ACPI to intercept RTC interrupts and to
    >forward them to the CPU. I could not test the patch, and know nothing
    >about ACPI. But this looks quite promising.



    >> And yes, Mandriva uses the util-linux version


    >So do the current and the (now frozen) future Debians, and so does
    >Ubuntu. They also call hwclock --hctosys *twice* at startup (!?).
    >They evaluate the drift rate from shutdown to shutdown, thus including
    >uptime. And they don't correct drift at all.


    >At the morning startup, those distros would give me an initial offset of
    >maybe 5 plain seconds, instead of the 5 milliseconds or better I get
    >routinely from hwclock 2.33



    >> Why does Brian not get his version back into util-linux?


    >To me, hwclock seems to be much better standalone than in a collection
    >of unrelated utilities. Active development vs. careless stagnation.


    I am certainly not suggesting careless stagnation. I would hope Brian would
    continue to develop it. It is just that distros are used to util-linux, and
    would have to strip out the hwclock in there and then install the
    standalone. It would seem far more likely to get adopted if the hwclock in
    the util-linux were the good one.

    Mind you idiocy on the part of the distributions is not unkown. Exactly the
    same thing has happpened re cdrecord vs wodim. Wodim is a fork from an
    ancient version of cdrecord, with minimal updates ( careless stagnation
    describes it well) while cdrecord is under active development. But the
    distros are almost all distributing the latter.

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2