Time reset - NTP

This is a discussion on Time reset - NTP ; Hal Murray wrote: >> The ntp log file shows when NTP steps the time. But then the potential harm >> is already done. Especially if the time moves backward, our server might >> have serious trouble. Is there a log ...

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

Thread: Time reset

  1. Re: Time reset

    Hal Murray wrote:
    >> The ntp log file shows when NTP steps the time. But then the potential harm
    >> is already done. Especially if the time moves backward, our server might
    >> have serious trouble. Is there a log event which indicates that the time is
    >> going to be reset in order to enable us to take appropriate action before
    >> the actual reset?

    >
    > I don't know of any way to get advanced warning when ntpd is about to
    > step the time.
    >


    You cannot have advanced warning before stepping. It doesn't know until
    it decides it needs to do it.

    > There are command line switches to prevent stepping and to allow
    > one step at startup time.
    >


    Yes. You can use -x to slew always.

    Danny

  2. Re: Time reset

    Danny Mayer wrote:
    > Hal Murray wrote:
    >
    >>>The ntp log file shows when NTP steps the time. But then the potential harm
    >>>is already done. Especially if the time moves backward, our server might
    >>>have serious trouble. Is there a log event which indicates that the time is
    >>>going to be reset in order to enable us to take appropriate action before
    >>>the actual reset?

    >>
    >>I don't know of any way to get advanced warning when ntpd is about to
    >>step the time.
    >>

    >
    >
    > You cannot have advanced warning before stepping. It doesn't know until
    > it decides it needs to do it.
    >
    >
    >>There are command line switches to prevent stepping and to allow
    >>one step at startup time.
    >>

    >
    >
    > Yes. You can use -x to slew always.
    >
    > Danny


    And if the clock is off by many hours, it could take days or weeks to
    synchronize.

    Use the -g option when you start ntpd. This will set the clock once
    only. IF your system is working properly, ntpd should be able to
    synchronize the clock fairly quickly and to keep it synchronized as long
    as it has a good source of time.

    If ntpd steps the time AFTER startup, you have a serious problem
    somewhere. IMHO the best way to deal with such stepping is to find out
    what's broken that makes stepping necessary and fix it!


  3. Re: Time reset

    Danny Mayer wrote:
    >
    > You cannot have advanced warning before stepping. It doesn't know until
    > it decides it needs to do it.


    Yes and no. You do not know that it will definitely step until the step
    occurs, but you know that it definitely won't step 900 seconds earlier.
    It can only step if it has been in the SPIK state for 900 seconds.
    Note that the comment tabulating the state transitions in 4.2p4 is wrong.

    >
    > Yes. You can use -x to slew always.


    -x doesn't prevent stepping. What it does, in recent ntpd's, is to set
    the magnitude of the offset before a step will be considered to 600ms,
    which is a strange choice, as the maximum value for which the kernel
    discipline is used is 499ms!

    If you actually want to completely stop stepping, you need to tinker the
    value to the magic value of zero.

    Note both -x and tinkering to zero effectively turn off the kernel
    discipline.

  4. Re: Time reset

    "jkvbe" writes:

    > The ntp log file shows when NTP steps the time. But then the potential harm
    > is already done. Especially if the time moves backward, our server might
    > have serious trouble. Is there a log event which indicates that the time is
    > going to be reset in order to enable us to take appropriate action before
    > the actual reset?


    Actually I think: Yes. The symptom typically is a "state" that is different
    from "4" over multiple polling/update intervals (ntpq -c rl).

    Ulrich

  5. Re: Time reset

    David Woolley writes:

    > Richard B. Gilbert wrote:
    >
    >> that people do some very strange things with computer clocks. I'm thinking,
    >> in particlar, of at least one individual who deliberately set his clock to
    >> an incorrect time in order to see if Ntpd would correct it.

    >
    > Many people do this. It is the naive users' way of testing that ntpd "works".


    Yes, but many forget to restart ntpd immediately after having chnaged the
    clock. Not having done so is as if the clock suddenly got a transient hardware
    defect. NTP is not designed repairing hardware defects. It syncs (good)
    clocks.

    (I had to say)

    Ulrich

  6. Re: Time reset

    Ulrich,

    The current (development) code has a new statistics file, called
    protostats, that records significant events, like system peer changes,
    mobilization/demobilization and error events. Among the events is a
    "spike detected" event, which indicates that an offset arrived greater
    than the step threshold (125 ms). Most of the time the spike is one-off
    and is simply discarded. However, if the offset persists beyound the
    stepout threshold (900 s), it will result in a step correction.

    Some might interpret the spike event as a warning that a step might
    occur 15 minutes later, but then would have to determine that this is
    indeed not a spike but a legitimate warning. Should it be interreted as
    a warning, it is not at all clear what an application should do. For
    instance, some IBM mainframers recommends that aall pplications should
    be completely shut down during the changeover between standard and
    daylight time. On the other hand, a protostats event triggers a trap,
    which could be caught by a monitoring program that kills power to the
    machine room.

    Dave

    Ulrich Windl wrote:

    > "jkvbe" writes:
    >
    >
    >>The ntp log file shows when NTP steps the time. But then the potential harm
    >>is already done. Especially if the time moves backward, our server might
    >>have serious trouble. Is there a log event which indicates that the time is
    >>going to be reset in order to enable us to take appropriate action before
    >>the actual reset?

    >
    >
    > Actually I think: Yes. The symptom typically is a "state" that is different
    > from "4" over multiple polling/update intervals (ntpq -c rl).
    >
    > Ulrich


  7. Re: Time reset

    Ulrich Windl wrote:
    > David Woolley writes:
    >
    >> Richard B. Gilbert wrote:
    >>
    >>> that people do some very strange things with computer clocks. I'm thinking,
    >>> in particlar, of at least one individual who deliberately set his clock to
    >>> an incorrect time in order to see if Ntpd would correct it.

    >> Many people do this. It is the naive users' way of testing that ntpd "works".

    >
    > Yes, but many forget to restart ntpd immediately after having chnaged the


    They don't forget. The naive users who run this sort of test have no
    idea that it is an unreasonable thing to do. In fact, restarting ntpd
    on the client would invalidate their test, as the test is about the
    ability of ntpd to track time jumps without any manual intervention.

    I'm not suggesting that ntpd should accommodate naive user tests, but
    just pointing out that they are rather common.

    > clock. Not having done so is as if the clock suddenly got a transient hardware
    > defect. NTP is not designed repairing hardware defects. It syncs (good)
    > clocks.
    >
    > (I had to say)
    >
    > Ulrich


  8. Re: Time reset

    David Woolley writes:

    >Ulrich Windl wrote:
    >> David Woolley writes:
    >>
    >>> Richard B. Gilbert wrote:
    >>>
    >>>> that people do some very strange things with computer clocks. I'm thinking,
    >>>> in particlar, of at least one individual who deliberately set his clock to
    >>>> an incorrect time in order to see if Ntpd would correct it.
    >>> Many people do this. It is the naive users' way of testing that ntpd "works".

    >>
    >> Yes, but many forget to restart ntpd immediately after having chnaged the


    >They don't forget. The naive users who run this sort of test have no
    >idea that it is an unreasonable thing to do. In fact, restarting ntpd
    >on the client would invalidate their test, as the test is about the
    >ability of ntpd to track time jumps without any manual intervention.


    >I'm not suggesting that ntpd should accommodate naive user tests, but
    >just pointing out that they are rather common.


    But ntp arguably should handle jumps in time or frequency faster than the
    hours or days it takes now.



    >> clock. Not having done so is as if the clock suddenly got a transient hardware
    >> defect. NTP is not designed repairing hardware defects. It syncs (good)
    >> clocks.
    >>
    >> (I had to say)
    >>
    >> Ulrich


  9. Re: Time reset

    Unruh wrote:
    []
    > But ntp arguably should handle jumps in time or frequency faster than
    > the hours or days it takes now.


    Why? A jump (to me) implies an error in the hardware. Who is to say that
    it's a one-off jump, or that it might not occur again in a few seconds,
    minutes ot hours? Should it not be the hardware which is corrected, not
    NTP?



    Cheers,
    David



  10. Re: Time reset

    David J Taylor wrote:
    > Unruh wrote:
    > []
    >> But ntp arguably should handle jumps in time or frequency faster than
    >> the hours or days it takes now.

    >
    > Why? A jump (to me) implies an error in the hardware. Who is to say that
    > it's a one-off jump, or that it might not occur again in a few seconds,
    > minutes ot hours? Should it not be the hardware which is corrected, not
    > NTP?


    I think one has to distinguish between jumps in time and in frequency.
    The naive test uses a jump in time, which is not a real life situation
    for serviceable equipment. However, jumps in frequency are quite
    possible as the result of rapid temperature changes, and as the results
    of aging processes in the electronics.

    Unruh's main issues with ntpd is actually its response to frequency
    transients, not its response to phase transients, and he is diluting his
    case by introducing phase transients. The one exception to this is the
    ntpd's poor response to the startup phase transient.

  11. Re: Time reset

    "David J Taylor" writes:

    >Unruh wrote:
    >[]
    >> But ntp arguably should handle jumps in time or frequency faster than
    >> the hours or days it takes now.


    >Why? A jump (to me) implies an error in the hardware. Who is to say that


    Or an error in software (missed timer ticks), or...

    >it's a one-off jump, or that it might not occur again in a few seconds,


    Yes, who is to say. So ntp should correct each one as quickly as possible.


    >minutes ot hours? Should it not be the hardware which is corrected, not
    >NTP?


    On that argument ntp should not do anything more than rdate did, since if
    the oscillator on the clocks were perfect there would be no need for
    anything but an single setting of the clock once per bootup. So ntp should
    not try to correct any errors but rather people should be advised to buy
    new hardware. The whole point to ntp is to try to keep the clocks operating
    as close to real time as possible in the real world-- with bad oscillators,
    time jumps in the OS, ....
    Agreed it ain't perfect, the question is how close to perfection can we get
    it.


    >


    >Cheers,
    >David




  12. Re: Time reset

    Unruh wrote:
    []
    >> minutes ot hours? Should it not be the hardware which is corrected,
    >> not NTP?

    >
    > On that argument ntp should not do anything more than rdate did,
    > since if
    > the oscillator on the clocks were perfect there would be no need for
    > anything but an single setting of the clock once per bootup. So ntp
    > should
    > not try to correct any errors but rather people should be advised to
    > buy
    > new hardware. The whole point to ntp is to try to keep the clocks
    > operating
    > as close to real time as possible in the real world-- with bad
    > oscillators,
    > time jumps in the OS, ....
    > Agreed it ain't perfect, the question is how close to perfection can
    > we get
    > it.


    I distinguish between drift, either the gradual drift with aging which I
    expect with crystal oscillators or the temperature dependence, and steps
    which I see as a hardware (or possibly software if poorly designed)
    problem. I would not expect NTP to sacrifice long-term stability just
    because the hardware is failing. An individual frequency step would be a
    once-off event. If it's more often than - what - once every three months,
    perhaps the hardware /should/ be replaced. If the OS causes time jumps,
    fix it!

    Everyone will have their own different criteria, of course.

    Cheers,
    David



  13. Re: Time reset

    On another note, I wish that NTP had an option to disable backward
    jumps in time. Is it something that has been considered before?

    TIA

  14. Re: Time reset

    Evandro Menezes wrote:
    > On another note, I wish that NTP had an option to disable backward
    > jumps in time. Is it something that has been considered before?
    >
    > TIA


    If you are seeing backward jumps on a running ntpd, something is VERY
    wrong. Normally the only time you will see a jump in either direction
    is when ntpd initializes. If you keep your server running 24x7 you
    should not see jumps at any other time. Some Linux systems have been
    reported to lose clock interrupts during periods of heavy disk activity
    but this results in forward steps.

  15. Re: Time reset

    Evandro,

    You will see the following message appearing in the archives about once
    per year. It may be time to repeat it again.

    The major assumption in the NTP design is that the operating system
    determines whether to accept a backward step or not. The original
    nanokernel design now used in Linux, FreeBSD and Tru64 forced monotonic
    forwared progress, although at reduced rate, unless the backward step is
    more than two seconds. In that case the assumption is a stuck bit in the
    clock counter or some other serious hardware flaw. Occasions like this
    are not common, but they are not rare either. The most common case is
    when starting the daemon the RTC time is a second or more from NTP time.

    Various generations of kernelmongers have cheerfully ignored that
    provision and substituted their own. The only thing NTP could do is to
    ignore a backard step and continue to ignore it forever, assuming the
    need to step back continures. You can of course tinker the step
    threshold larger than the default 128 ms, but you must accept that the
    time to complete a correction and assume applications are synchronized
    is 2000 s for every second of correction.

    Some systems, including Linux, Solaris and IRIX, have replaced the
    original Unix adjtime() design with what they believe is a fast
    adjustemt algorithm. This introduces an extra pole in the transient
    response and results in large overcorrections and overshoot, especially
    with large corrections. The effect is that applications swing in and out
    of synchronization until the transients die down.

    If the above constraints are not acceptable, I strongly advise you to
    avoid using NTP.

    Dave

    Evandro Menezes wrote:

    > On another note, I wish that NTP had an option to disable backward
    > jumps in time. Is it something that has been considered before?
    >
    > TIA


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2