NTP Cheat Sheet - NTP

This is a discussion on NTP Cheat Sheet - NTP ; Hi! I created a NTP cheat sheet as a short reference for the NTP configuration file statements and other NTP related stuff. I am pretty sure that I missed something important and I would appreciate any feedback from you if ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: NTP Cheat Sheet

  1. NTP Cheat Sheet

    Hi!

    I created a NTP cheat sheet as a short reference for the NTP configuration file
    statements and other NTP related stuff. I am pretty sure that I missed something
    important and I would appreciate any feedback from you if you can spare a few
    minutes.

    Here is the link to our NTP download page:
    http://www.meinberg.de/english/sw/ntp.htm

    You'll find the cheat sheet near the bottom of this page.

    Thanks,
    Heiko

  2. Re: NTP Cheat Sheet

    Heiko Gerstung wrote:
    > Hi!
    >
    > I created a NTP cheat sheet as a short reference for the NTP
    > configuration file statements and other NTP related stuff. I am pretty
    > sure that I missed something important and I would appreciate any
    > feedback from you if you can spare a few minutes.
    >
    > Here is the link to our NTP download page:
    > http://www.meinberg.de/english/sw/ntp.htm
    >
    > You'll find the cheat sheet near the bottom of this page.
    >
    > Thanks,
    > Heiko


    The first thing I noticed was text describing how to change the MINPOLL
    and MAXPOLL options. I would add that tinkering with MINPOLL and
    MAXPOLL is usually not a good idea. If you need to ask how, you
    probably should not be changing them.

  3. Re: NTP Cheat Sheet

    Richard B. Gilbert schrieb:
    > Heiko Gerstung wrote:
    >> Hi!
    >>
    >> I created a NTP cheat sheet as a short reference for the NTP
    >> configuration file statements and other NTP related stuff. I am pretty
    >> sure that I missed something important and I would appreciate any
    >> feedback from you if you can spare a few minutes.
    >>
    >> Here is the link to our NTP download page:
    >> http://www.meinberg.de/english/sw/ntp.htm
    >>
    >> You'll find the cheat sheet near the bottom of this page.
    >>
    >> Thanks,
    >> Heiko

    >
    > The first thing I noticed was text describing how to change the MINPOLL
    > and MAXPOLL options. I would add that tinkering with MINPOLL and
    > MAXPOLL is usually not a good idea. If you need to ask how, you
    > probably should not be changing them.


    Thanks a lot for your feedback!

    In my experience it definitely helps a lot to set the minpoll/maxpoll values to
    a lower value when talking to reference clock drivers and your local NTP
    servers. On our time server appliances we use minpoll 4 maxpoll 4 for talking to
    the integrated refclock (GPS, MSF, DCF77 or IRIG) and this dramatically improves
    the reaction times of ntpd when it comes to things like initial synchronization,
    reception outtages and so on. Although the parse driver (which we use for all
    our refclocks) already has a "fast sync" feature which allows ntpd to accept the
    refclock after a few seconds (something like iburst for refclocks), other
    refclock drivers can benefit from being able to pass on sync data to ntpd four
    times faster than the default.

    To me there is no sense in only getting one sample in 64 seconds when your
    expensive and highly accurate hardware reference clock offers one very good
    sample every second.

    But well, this cheat sheet was intended to be used by people with some knowledge
    of NTP since there are a lot more advanced configuration options mentioned that
    are probably not very interesting for absolute NTP beginners.

    Best regards,
    Heiko

  4. Re: NTP Cheat Sheet

    Heiko,

    Be careful when making generalizations about refclocks. Some, including
    the Spectracom, Austron, Traconex, TrueTime and others using the median
    filter will not workproperly at other than default poll. Same for the
    modem and audio drivers.

    I don't knkow what version you are using, but the current (development)
    version sets the time on the first poll received from a reference clock.
    But, !! note carefully !! On one of our servers the first poll recieved
    sometimes has a large error (400 ms) that torques the time until brought
    right 15 minutes later. Frankly, our servers run for months without
    disturbance, so an initial delay to synchronize to a reference clock is
    not a big deal.

    As a general rule of thumb and confirmed by theory and practice, the
    nominal errors increase by a factor of two for each fourfold increase in
    poll interval; thus, reducing the poll from 64 to 16 s reduces the
    errors by half. This is only true when the time constant is above the
    Allan intercept, which is usually in the vicinity of 2000 s. By design,
    the time constant is 32 times the poll interval, so 16-s poll is on the
    hairy edge.

    Dave

    Heiko Gerstung wrote:
    > Richard B. Gilbert schrieb:
    >
    >> Heiko Gerstung wrote:
    >>
    >>> Hi!
    >>>
    >>> I created a NTP cheat sheet as a short reference for the NTP
    >>> configuration file statements and other NTP related stuff. I am
    >>> pretty sure that I missed something important and I would appreciate
    >>> any feedback from you if you can spare a few minutes.
    >>>
    >>> Here is the link to our NTP download page:
    >>> http://www.meinberg.de/english/sw/ntp.htm
    >>>
    >>> You'll find the cheat sheet near the bottom of this page.
    >>>
    >>> Thanks,
    >>> Heiko

    >>
    >>
    >> The first thing I noticed was text describing how to change the
    >> MINPOLL and MAXPOLL options. I would add that tinkering with MINPOLL
    >> and MAXPOLL is usually not a good idea. If you need to ask how, you
    >> probably should not be changing them.

    >
    >
    > Thanks a lot for your feedback!
    >
    > In my experience it definitely helps a lot to set the minpoll/maxpoll
    > values to a lower value when talking to reference clock drivers and your
    > local NTP servers. On our time server appliances we use minpoll 4
    > maxpoll 4 for talking to the integrated refclock (GPS, MSF, DCF77 or
    > IRIG) and this dramatically improves the reaction times of ntpd when it
    > comes to things like initial synchronization, reception outtages and so
    > on. Although the parse driver (which we use for all our refclocks)
    > already has a "fast sync" feature which allows ntpd to accept the
    > refclock after a few seconds (something like iburst for refclocks),
    > other refclock drivers can benefit from being able to pass on sync data
    > to ntpd four times faster than the default.
    >
    > To me there is no sense in only getting one sample in 64 seconds when
    > your expensive and highly accurate hardware reference clock offers one
    > very good sample every second.
    >
    > But well, this cheat sheet was intended to be used by people with some
    > knowledge of NTP since there are a lot more advanced configuration
    > options mentioned that are probably not very interesting for absolute
    > NTP beginners.
    >
    > Best regards,
    > Heiko


  5. Re: NTP Cheat Sheet

    > From: "David L. Mills"
    > Date: Wed, 07 May 2008 19:51:20 +0000
    > Sender: questions-bounces+oberman=es.net@lists.ntp.org
    >
    >
    > Heiko,
    >
    > Be careful when making generalizations about refclocks. Some, including
    > the Spectracom, Austron, Traconex, TrueTime and others using the median
    > filter will not workproperly at other than default poll. Same for the
    > modem and audio drivers.


    I assume that this is driver, not device specific.

    server 127.127.5.1 prefer minpoll 4 maxpoll 4
    fudge 127.127.5.1 refid CDMA
    fudge 127.127.5.1 time1 .010
    server 127.127.22.1 minpoll 4 maxpoll 4
    fudge 127.127.22.1 flag3 1

    What about the PPS driver when used with one of these? I use EndRun CDMA
    clocks emulating TrueTime with PPS and EndRun recommends a MINPOLL and
    MAXPOLL of 4. Is that bad advice in such a configuration? If it is
    significant, I use FreeBSD on all of my ntp servers.
    --
    R. Kevin Oberman, Network Engineer
    Energy Sciences Network (ESnet)
    Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
    E-mail: oberman@es.net Phone: +1 510 486-8634
    Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

    _______________________________________________
    questions mailing list
    questions@lists.ntp.org
    https://lists.ntp.org/mailman/listinfo/questions

    --- StripMime Report -- processed MIME parts ---
    multipart/mixed
    multipart/signed
    text/plain (text body -- kept)
    application/pgp-signature
    text/plain (text body -- kept)
    ---

  6. Re: NTP Cheat Sheet

    Keven,

    The TrueTime driver that lives here supports all known TrueTime
    receivers, including GPS, WWVB and GOES. I strongly suspect one or
    another of those receivers would not work if the poll interval was
    tinkered. EndRun apparently has cloned most or all that driver and may
    have modified it. If they recommend minpoll 4, run that end.

    Dave

    Kevin Oberman wrote:
    >>From: "David L. Mills"
    >>Date: Wed, 07 May 2008 19:51:20 +0000
    >>Sender: questions-bounces+oberman=es.net@lists.ntp.org
    >>
    >>
    >>Heiko,
    >>
    >>Be careful when making generalizations about refclocks. Some, including
    >>the Spectracom, Austron, Traconex, TrueTime and others using the median
    >>filter will not workproperly at other than default poll. Same for the
    >>modem and audio drivers.

    >
    >
    > I assume that this is driver, not device specific.
    >
    > server 127.127.5.1 prefer minpoll 4 maxpoll 4
    > fudge 127.127.5.1 refid CDMA
    > fudge 127.127.5.1 time1 .010
    > server 127.127.22.1 minpoll 4 maxpoll 4
    > fudge 127.127.22.1 flag3 1
    >
    > What about the PPS driver when used with one of these? I use EndRun CDMA
    > clocks emulating TrueTime with PPS and EndRun recommends a MINPOLL and
    > MAXPOLL of 4. Is that bad advice in such a configuration? If it is
    > significant, I use FreeBSD on all of my ntp servers.


  7. Re: NTP Cheat Sheet

    Dave,

    Thanks for the quick response, but I guess I failed to make one point
    clear.

    EndRun supplies only the hardware. It is the Ct which as only a serial
    interface which is plugged into a standard COM port on the server. They
    don't provide any software at all. The clock just provides the time
    string every second (with an offset of about 10 ms. and jitter in the
    area of 3-5 ms.) and a very accurate PPS which allows us sync within
    about three usec. (The clock spec is better than ten usec, but three
    seems the norm.)

    I am running 4.2.0-a using the stock TrueTime and PPS drivers. The
    FreeBSD kernel has PPS support included, so any filtering in the
    TrueTime driver should be of little or no impact.

    I am assuming than as long as I am using PPS and training the TrueTime
    source, a minpoll of 4 is reasonable and I just wanted to make sure that
    I am not wrong in doing this.
    --
    R. Kevin Oberman, Network Engineer
    Energy Sciences Network (ESnet)
    Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
    E-mail: oberman@es.net Phone: +1 510 486-8634
    Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

    > From: "David L. Mills"
    > Date: Wed, 07 May 2008 21:38:40 +0000
    > Sender: questions-bounces+oberman=es.net@lists.ntp.org
    >
    >
    > Keven,
    >
    > The TrueTime driver that lives here supports all known TrueTime
    > receivers, including GPS, WWVB and GOES. I strongly suspect one or
    > another of those receivers would not work if the poll interval was
    > tinkered. EndRun apparently has cloned most or all that driver and may
    > have modified it. If they recommend minpoll 4, run that end.
    >
    > Dave
    >
    > Kevin Oberman wrote:
    > >>From: "David L. Mills"
    > >>Date: Wed, 07 May 2008 19:51:20 +0000
    > >>Sender: questions-bounces+oberman=es.net@lists.ntp.org
    > >>
    > >>
    > >>Heiko,
    > >>
    > >>Be careful when making generalizations about refclocks. Some, including
    > >>the Spectracom, Austron, Traconex, TrueTime and others using the median
    > >>filter will not workproperly at other than default poll. Same for the
    > >>modem and audio drivers.

    > >
    > >
    > > I assume that this is driver, not device specific.
    > >
    > > server 127.127.5.1 prefer minpoll 4 maxpoll 4
    > > fudge 127.127.5.1 refid CDMA
    > > fudge 127.127.5.1 time1 .010
    > > server 127.127.22.1 minpoll 4 maxpoll 4
    > > fudge 127.127.22.1 flag3 1
    > >
    > > What about the PPS driver when used with one of these? I use EndRun CDMA
    > > clocks emulating TrueTime with PPS and EndRun recommends a MINPOLL and
    > > MAXPOLL of 4. Is that bad advice in such a configuration? If it is
    > > significant, I use FreeBSD on all of my ntp servers.

    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.org
    > https://lists.ntp.org/mailman/listinfo/questions
    >


    _______________________________________________
    questions mailing list
    questions@lists.ntp.org
    https://lists.ntp.org/mailman/listinfo/questions

    --- StripMime Report -- processed MIME parts ---
    multipart/mixed
    multipart/signed
    text/plain (text body -- kept)
    application/pgp-signature
    text/plain (text body -- kept)
    ---

  8. Re: NTP Cheat Sheet

    Kevin,

    Strange. I have an EndRun Cntp, bu it has an Ethernet interface. If 4
    works for you use it. That's a pretty grotty driver with all kinds of
    bandaids to deal with long forgotten radios; I wonder why EndRun chose
    that driver...

    Dave

    Kevin Oberman wrote:
    > Dave,
    >
    > Thanks for the quick response, but I guess I failed to make one point
    > clear.
    >
    > EndRun supplies only the hardware. It is the Ct which as only a serial
    > interface which is plugged into a standard COM port on the server. They
    > don't provide any software at all. The clock just provides the time
    > string every second (with an offset of about 10 ms. and jitter in the
    > area of 3-5 ms.) and a very accurate PPS which allows us sync within
    > about three usec. (The clock spec is better than ten usec, but three
    > seems the norm.)
    >
    > I am running 4.2.0-a using the stock TrueTime and PPS drivers. The
    > FreeBSD kernel has PPS support included, so any filtering in the
    > TrueTime driver should be of little or no impact.
    >
    > I am assuming than as long as I am using PPS and training the TrueTime
    > source, a minpoll of 4 is reasonable and I just wanted to make sure that
    > I am not wrong in doing this.


  9. Re: NTP Cheat Sheet

    Heiko Gerstung wrote:
    > local NTP servers. On our time server appliances we use minpoll 4
    > maxpoll 4 for talking to the integrated refclock (GPS, MSF, DCF77 or
    > IRIG) and this dramatically improves the reaction times of ntpd when it


    Dave Mills, you again need to note the "market" perception that ntpd has
    poor transient responses.

    > comes to things like initial synchronization, reception outtages and so
    > on. Although the parse driver (which we use for all our refclocks)


    As I understand it, maxpoll has rather limited impact. The most it may
    do is speed up the detection of a phase hit. As I understand it setting
    a low maxpoll simply causes oversampling of the data without actually
    limiting the minimum filter bandwidth. I suspect that is why the
    subsequent discussion only mentions minpoll.

    >
    > To me there is no sense in only getting one sample in 64 seconds when
    > your expensive and highly accurate hardware reference clock offers one
    > very good sample every second.


    Most highly accurate reference clocks do not produce high accuracy on
    their NMEA output, but rather on their PPS one. ntpd only requires the
    NMEA input to be good to a second, in that case.
    >


  10. Re: NTP Cheat Sheet

    David Woolley schrieb:
    > Heiko Gerstung wrote:
    >> local NTP servers. On our time server appliances we use minpoll 4
    >> maxpoll 4 for talking to the integrated refclock (GPS, MSF, DCF77 or
    >> IRIG) and this dramatically improves the reaction times of ntpd when it

    >
    > Dave Mills, you again need to note the "market" perception that ntpd has
    > poor transient responses.
    >
    >> comes to things like initial synchronization, reception outtages and
    >> so on. Although the parse driver (which we use for all our refclocks)

    >
    > As I understand it, maxpoll has rather limited impact. The most it may
    > do is speed up the detection of a phase hit. As I understand it setting
    > a low maxpoll simply causes oversampling of the data without actually
    > limiting the minimum filter bandwidth. I suspect that is why the
    > subsequent discussion only mentions minpoll.


    For me maxpoll is an important parameter as well because ntpd switches to larger
    polling intervals pretty fast and for a lot of our customers it is important
    that ntpd recognizes as fast as possible if a GPS signal is lost or the GPS
    receiver/IRIG time code reader/AM radio looses sync for some other reason. They
    want the unit to switch as soon as possible to a fallback source which will take
    significantly longer with a polling interval of 64s when compared to 16s ... the
    same applies when the refclock recovers after becoming unsynchronized.

    >> To me there is no sense in only getting one sample in 64 seconds when
    >> your expensive and highly accurate hardware reference clock offers one
    >> very good sample every second.


    > Most highly accurate reference clocks do not produce high accuracy on
    > their NMEA output, but rather on their PPS one. ntpd only requires the
    > NMEA input to be good to a second, in that case.


    Yes, but in our case the parse driver utilizes the PPSAPI under Linux (as does
    the NMEA driver) which means that your refclock driver gets a measurement (based
    on the PPS) each second.

    Regards,
    Heiko

  11. Re: NTP Cheat Sheet

    Dave,

    When introducing our CDMA technology, EndRun thought it wise to make the
    initial product emulate existing hardware that had already been
    interfaced to unix machines via the serial port and "gadget boxes." The
    CDMA engine which is inside both the Ct and your Cntp emulates both the
    Truetime and Spectracom time strings, with 1PPS on DCD. In addition, it
    emulates the Trimble Palisade event capture mode on the CTS input, with
    30 ns resolution. One benefit to this driver is high resolution
    capability on the Windows platform, another is not needing to mess with
    kernels that don't natively support high-resolution 1PPS timetagging.

    Users of the Ct can choose the emulation mode they like and use the
    standard drivers in the stock ntp distribution. However, all of our ntp
    servers operate the CDMA or GPS engine in the CTS event capture mode
    with a heavily customized refclock driver.

    While developing our first generation ntp servers (your Cntp is one of
    these) using off the shelf X86 embedded single board computers running
    linux, we found that longer poll intervals definitely exposed the
    instabilities of the uncompensated crystals used on these boards. We
    found that with high measurement precision and holding the poll interval
    at 16 seconds, one microsecond level offset control could be maintained
    reliably, and have never experienced any loop damping issues.

    Our current products contain our own purpose-built X86 core with clocks
    that are hardware phase locked to the main system disciplined
    oscillator, which could be TCXO, OCXO or Rubidium. In these units, a
    shorter polling interval is really only an issue at startup for more
    rapid ntp lock because the kernel clock is rock solid between polls.

    Bruce Penrod

    David L. Mills wrote:
    > Kevin,
    >
    > Strange. I have an EndRun Cntp, bu it has an Ethernet interface. If 4
    > works for you use it. That's a pretty grotty driver with all kinds of
    > bandaids to deal with long forgotten radios; I wonder why EndRun chose
    > that driver...
    >
    > Dave
    >
    > Kevin Oberman wrote:
    >> Dave,
    >>
    >> Thanks for the quick response, but I guess I failed to make one point
    >> clear.
    >> EndRun supplies only the hardware. It is the Ct which as only a serial
    >> interface which is plugged into a standard COM port on the server. They
    >> don't provide any software at all. The clock just provides the time
    >> string every second (with an offset of about 10 ms. and jitter in the
    >> area of 3-5 ms.) and a very accurate PPS which allows us sync within
    >> about three usec. (The clock spec is better than ten usec, but three
    >> seems the norm.)
    >>
    >> I am running 4.2.0-a using the stock TrueTime and PPS drivers. The
    >> FreeBSD kernel has PPS support included, so any filtering in the
    >> TrueTime driver should be of little or no impact.
    >>
    >> I am assuming than as long as I am using PPS and training the TrueTime
    >> source, a minpoll of 4 is reasonable and I just wanted to make sure that
    >> I am not wrong in doing this.


  12. Re: NTP Cheat Sheet

    Dave,

    Not really strange. The Ct is an old design from EndRun that is very
    small and allows the server to run additional software. The latter is
    the reason we continue to deploy the Ct. (Just bought 10 more and are
    about to order another 10.)

    The systems to which these clocks are connected need to also run OWAMP
    , a one-way ping tool. It is only as
    accurate as the times on the client and server, so we need single digit
    usec. sync between the systems which are scattered all over the
    country.

    It's quite nice to have a tool that tells you that a circuit has moved
    from working to protect because you can see the propagation time
    increase by 40 usec. and we can do exactly that. It is a key part of our
    high performance network monitoring system.

    That is why we have found the Ct to be the ideal unit for our
    purposes. It can emulate several different clocks including TrueTime and
    Trimble Palisade, but, in our testing, we concluded that Either TrueTime
    or Spectracom emulation with PPS kernel support provided the most
    accurate and stable time.

    In any case, thank you for the information. While I've been working with
    NTP since at least V2 days, I won't claim to really understand all of
    the gory details and some of the non-intuitive behaviors.
    --
    R. Kevin Oberman, Network Engineer
    Energy Sciences Network (ESnet)
    Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
    E-mail: oberman@es.net Phone: +1 510 486-8634
    Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

    > From: "David L. Mills"
    > Date: Thu, 08 May 2008 03:21:49 +0000
    > Sender: questions-bounces+oberman=es.net@lists.ntp.org
    >
    >
    > Kevin,
    >
    > Strange. I have an EndRun Cntp, bu it has an Ethernet interface. If 4
    > works for you use it. That's a pretty grotty driver with all kinds of
    > bandaids to deal with long forgotten radios; I wonder why EndRun chose
    > that driver...
    >
    > Dave
    >
    > Kevin Oberman wrote:
    > > Dave,
    > >
    > > Thanks for the quick response, but I guess I failed to make one point
    > > clear.
    > >
    > > EndRun supplies only the hardware. It is the Ct which as only a serial
    > > interface which is plugged into a standard COM port on the server. They
    > > don't provide any software at all. The clock just provides the time
    > > string every second (with an offset of about 10 ms. and jitter in the
    > > area of 3-5 ms.) and a very accurate PPS which allows us sync within
    > > about three usec. (The clock spec is better than ten usec, but three
    > > seems the norm.)
    > >
    > > I am running 4.2.0-a using the stock TrueTime and PPS drivers. The
    > > FreeBSD kernel has PPS support included, so any filtering in the
    > > TrueTime driver should be of little or no impact.
    > >
    > > I am assuming than as long as I am using PPS and training the TrueTime
    > > source, a minpoll of 4 is reasonable and I just wanted to make sure that
    > > I am not wrong in doing this.

    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.org
    > https://lists.ntp.org/mailman/listinfo/questions
    >


    _______________________________________________
    questions mailing list
    questions@lists.ntp.org
    https://lists.ntp.org/mailman/listinfo/questions

    --- StripMime Report -- processed MIME parts ---
    multipart/mixed
    multipart/signed
    text/plain (text body -- kept)
    application/pgp-signature
    text/plain (text body -- kept)
    ---

  13. Re: NTP Cheat Sheet

    Heiko Gerstung wrote:
    > For me maxpoll is an important parameter as well because ntpd switches
    > to larger polling intervals pretty fast and for a lot of our customers
    > it is important that ntpd recognizes as fast as possible if a GPS signal
    > is lost or the GPS receiver/IRIG time code reader/AM radio looses sync


    But ntpd should only switch to a long poll interval if it believes that
    it will not accumulate a significant error if it drifts for many times
    the poll interval, so, if the poll interval is long the time available
    before you need to switch to an alternative source is also long.

    I think what you are actually saying is that you believe there is a bug
    in ntpd that causes it to increase the loop time constant prematurely.

    The other possibility is that you are are saying that your reference
    clocks will give out wrong times for a significant period before they
    declare themselves down, and you want the accumuated error wiped out as
    soon as possible after the clock discovers its is giving bad times.
    Even then, a long loop time constant will require bad input for a long
    time to cause real problems.

    However, it looks to me as though the code only ever uses the minpoll
    value for reference clocks unless the clock driver itself actually
    overrides the NTP_FIXPOLL flag, or the poll rate, directly. I'm not
    sure I've not missed something, though, and I don't have a system with a
    reference clock to check.


    > for some other reason. They want the unit to switch as soon as possible
    > to a fallback source which will take significantly longer with a polling
    > interval of 64s when compared to 16s ... the same applies when the
    > refclock recovers after becoming unsynchronized.


    There is a better case for this, always assuming that maxpoll is
    relevant for reference clocks.


  14. Re: NTP Cheat Sheet

    David Woolley schrieb:
    > Heiko Gerstung wrote:
    >> For me maxpoll is an important parameter as well because ntpd switches
    >> to larger polling intervals pretty fast and for a lot of our customers
    >> it is important that ntpd recognizes as fast as possible if a GPS
    >> signal is lost or the GPS receiver/IRIG time code reader/AM radio
    >> looses sync

    >
    > But ntpd should only switch to a long poll interval if it believes that
    > it will not accumulate a significant error if it drifts for many times
    > the poll interval, so, if the poll interval is long the time available
    > before you need to switch to an alternative source is also long.
    >
    > I think what you are actually saying is that you believe there is a bug
    > in ntpd that causes it to increase the loop time constant prematurely.
    >
    > The other possibility is that you are are saying that your reference
    > clocks will give out wrong times for a significant period before they
    > declare themselves down, and you want the accumuated error wiped out as
    > soon as possible after the clock discovers its is giving bad times. Even
    > then, a long loop time constant will require bad input for a long time
    > to cause real problems.


    No, I apologize if I did not make this clear. I said that our customers want
    ntpd to show that something is wrong with the internal time source, probably for
    management reasons. Additionally they often deploy more than one refclock and if
    one of them looses sync, they want the second unit to take over.

    I strongly assume that ntpd is correctly increasing the polling interval.

    Of course our refclocks will not give out wrong time for a significant period
    :-) ...

    > However, it looks to me as though the code only ever uses the minpoll
    > value for reference clocks unless the clock driver itself actually
    > overrides the NTP_FIXPOLL flag, or the poll rate, directly. I'm not
    > sure I've not missed something, though, and I don't have a system with a
    > reference clock to check.


    I have a system with a refclock and it honours the minpoll / maxpoll settings
    just like other association types do.

    >> for some other reason. They want the unit to switch as soon as
    >> possible to a fallback source which will take significantly longer
    >> with a polling interval of 64s when compared to 16s ... the same
    >> applies when the refclock recovers after becoming unsynchronized.

    >
    > There is a better case for this, always assuming that maxpoll is
    > relevant for reference clocks.


    What do you mean with "better case"?

    Best Regards,
    Heiko

  15. Re: NTP Cheat Sheet

    Heiko Gerstung writes:

    >David Woolley schrieb:
    >> Heiko Gerstung wrote:
    >>> For me maxpoll is an important parameter as well because ntpd switches
    >>> to larger polling intervals pretty fast and for a lot of our customers
    >>> it is important that ntpd recognizes as fast as possible if a GPS
    >>> signal is lost or the GPS receiver/IRIG time code reader/AM radio
    >>> looses sync

    >>
    >> But ntpd should only switch to a long poll interval if it believes that
    >> it will not accumulate a significant error if it drifts for many times
    >> the poll interval, so, if the poll interval is long the time available
    >> before you need to switch to an alternative source is also long.
    >>
    >> I think what you are actually saying is that you believe there is a bug
    >> in ntpd that causes it to increase the loop time constant prematurely.
    >>
    >> The other possibility is that you are are saying that your reference
    >> clocks will give out wrong times for a significant period before they
    >> declare themselves down, and you want the accumuated error wiped out as
    >> soon as possible after the clock discovers its is giving bad times. Even
    >> then, a long loop time constant will require bad input for a long time
    >> to cause real problems.


    >No, I apologize if I did not make this clear. I said that our customers want
    >ntpd to show that something is wrong with the internal time source, probably for
    >management reasons. Additionally they often deploy more than one refclock and if
    >one of them looses sync, they want the second unit to take over.


    >I strongly assume that ntpd is correctly increasing the polling interval.


    >Of course our refclocks will not give out wrong time for a significant period
    >:-) ...


    Why would you want the poll interval to increase on a refclock? It is not
    as though you are going to swamp it even if you poll it every 16 sec.



    >> However, it looks to me as though the code only ever uses the minpoll
    >> value for reference clocks unless the clock driver itself actually
    >> overrides the NTP_FIXPOLL flag, or the poll rate, directly. I'm not
    >> sure I've not missed something, though, and I don't have a system with a
    >> reference clock to check.


    >I have a system with a refclock and it honours the minpoll / maxpoll settings
    >just like other association types do.


    >>> for some other reason. They want the unit to switch as soon as
    >>> possible to a fallback source which will take significantly longer
    >>> with a polling interval of 64s when compared to 16s ... the same
    >>> applies when the refclock recovers after becoming unsynchronized.

    >>
    >> There is a better case for this, always assuming that maxpoll is
    >> relevant for reference clocks.


    >What do you mean with "better case"?


    >Best Regards,
    > Heiko


  16. Re: NTP Cheat Sheet

    David,

    There is need to dispell urban legends here. First, the only reference
    clock driver that uses anything other than minpoll is the ACTS driver.
    All others do not increase the poll interval under any circumstances.
    Second, there is no failover at all. The design is that more than one
    reference clock driver is happily supported at the same time. Their
    contributions are continuously evaluated and mitigated, so there is no
    delay in using one or the other or both. If the intended behavior is to
    "fail over" in the usual sense of those words, you should be using
    something other than NTP>

    Dave

    David Woolley wrote:
    > Heiko Gerstung wrote:
    >
    >> For me maxpoll is an important parameter as well because ntpd switches
    >> to larger polling intervals pretty fast and for a lot of our customers
    >> it is important that ntpd recognizes as fast as possible if a GPS
    >> signal is lost or the GPS receiver/IRIG time code reader/AM radio
    >> looses sync

    >
    >
    > But ntpd should only switch to a long poll interval if it believes that
    > it will not accumulate a significant error if it drifts for many times
    > the poll interval, so, if the poll interval is long the time available
    > before you need to switch to an alternative source is also long.
    >
    > I think what you are actually saying is that you believe there is a bug
    > in ntpd that causes it to increase the loop time constant prematurely.
    >
    > The other possibility is that you are are saying that your reference
    > clocks will give out wrong times for a significant period before they
    > declare themselves down, and you want the accumuated error wiped out as
    > soon as possible after the clock discovers its is giving bad times. Even
    > then, a long loop time constant will require bad input for a long time
    > to cause real problems.
    >
    > However, it looks to me as though the code only ever uses the minpoll
    > value for reference clocks unless the clock driver itself actually
    > overrides the NTP_FIXPOLL flag, or the poll rate, directly. I'm not
    > sure I've not missed something, though, and I don't have a system with a
    > reference clock to check.
    >
    >
    >> for some other reason. They want the unit to switch as soon as
    >> possible to a fallback source which will take significantly longer
    >> with a polling interval of 64s when compared to 16s ... the same
    >> applies when the refclock recovers after becoming unsynchronized.

    >
    >
    > There is a better case for this, always assuming that maxpoll is
    > relevant for reference clocks.
    >


  17. Re: NTP Cheat Sheet

    David L. Mills wrote:
    >
    > There is need to dispell urban legends here. First, the only reference
    > clock driver that uses anything other than minpoll is the ACTS driver.


    You introduced the possibility that there were exceptions, yourself,
    earlier in the thread; I was just caveating what I wrote to cater for that.

    > All others do not increase the poll interval under any circumstances.


    Yes. That's how I read the code; however Heiko appears to have
    empirical evidence to the contrary. (One thought I had is that there
    seems to be more than one state variable involved and maybe ntpq peers
    doesn't show the actual poll interval)

    > Second, there is no failover at all. The design is that more than one


    I suspect failover is concept that customers and salesmen like. I do
    try to stress that ntpd averages multiple sources (and the weighting
    isn't tied to the current system peer). One other aspect of that
    particular myth is the concept of clock hopping. I think clock hopping
    can only happen if you have enough clocks that the set of retained
    clocks changes. I'm sure a lot of people believe that ntpd only uses
    data from the current "system peer".

    One caveat, as I understand it, if they used a prefer keyword, ntpd
    would failover from that server to an average of all the others.

    > reference clock driver is happily supported at the same time. Their
    > contributions are continuously evaluated and mitigated, so there is no
    > delay in using one or the other or both. If the intended behavior is to
    > "fail over" in the usual sense of those words, you should be using
    > something other than NTP>


    I think you meant Heiko should be.

  18. Re: NTP Cheat Sheet

    David,

    The flag FLAG_FIXPOLL is defined for all reference clock driverss except
    ACTS. With this flag defined, the poll interval is fixed at minpoll. See
    ntp_refclock.c and ntp_proto.c.

    Having thought about it, there actually are two scenarios involving
    failover, one with the local clock driver, the other with the modem
    driver. These driver are disabled unless all other sources are lost or
    not configured. For the local clock driver, this was done to avoid nasty
    cases when the local clock driver escaped to the Internet at large,
    which has in fact happened on occasion.

    Dave

    David Woolley wrote:
    > David L. Mills wrote:
    >
    >>
    >> There is need to dispell urban legends here. First, the only reference
    >> clock driver that uses anything other than minpoll is the ACTS driver.

    >
    >
    > You introduced the possibility that there were exceptions, yourself,
    > earlier in the thread; I was just caveating what I wrote to cater for that.
    >
    >> All others do not increase the poll interval under any circumstances.

    >
    >
    > Yes. That's how I read the code; however Heiko appears to have
    > empirical evidence to the contrary. (One thought I had is that there
    > seems to be more than one state variable involved and maybe ntpq peers
    > doesn't show the actual poll interval)
    >
    >> Second, there is no failover at all. The design is that more than one

    >
    >
    > I suspect failover is concept that customers and salesmen like. I do
    > try to stress that ntpd averages multiple sources (and the weighting
    > isn't tied to the current system peer). One other aspect of that
    > particular myth is the concept of clock hopping. I think clock hopping
    > can only happen if you have enough clocks that the set of retained
    > clocks changes. I'm sure a lot of people believe that ntpd only uses
    > data from the current "system peer".
    >
    > One caveat, as I understand it, if they used a prefer keyword, ntpd
    > would failover from that server to an average of all the others.
    >
    >> reference clock driver is happily supported at the same time. Their
    >> contributions are continuously evaluated and mitigated, so there is no
    >> delay in using one or the other or both. If the intended behavior is
    >> to "fail over" in the usual sense of those words, you should be using
    >> something other than NTP>

    >
    >
    > I think you meant Heiko should be.


  19. Re: NTP Cheat Sheet

    David L. Mills schrieb:
    > David,
    >
    > The flag FLAG_FIXPOLL is defined for all reference clock driverss except
    > ACTS. With this flag defined, the poll interval is fixed at minpoll. See
    > ntp_refclock.c and ntp_proto.c.


    OK, that explains it :-) We use "minpoll 4 maxpoll 4" because we want the
    reference clock to be polled every 16s ... Looks like "minpoll" directly affects
    the maximum polling interval for refclocks (because there is no "minpoll" or
    "maxpoll", just a "fixpoll" functionality).

    > Having thought about it, there actually are two scenarios involving
    > failover, one with the local clock driver, the other with the modem
    > driver. These driver are disabled unless all other sources are lost or
    > not configured. For the local clock driver, this was done to avoid nasty
    > cases when the local clock driver escaped to the Internet at large,
    > which has in fact happened on occasion.


    The "Failover" mode is something engineers in most industry segments know and
    use for all kinds of mission critical stuff, it is often hard or impossible to
    convince them that for time synchronization a majority approach is the best
    solution. For some strange reason it sounds a little bit suspicious when a time
    server manufacturer tells you that "you should use four instead of two time
    servers to be protected against ..." :-)

    Heiko

    >
    > Dave
    >
    > David Woolley wrote:
    >> David L. Mills wrote:
    >>
    >>>
    >>> There is need to dispell urban legends here. First, the only
    >>> reference clock driver that uses anything other than minpoll is the
    >>> ACTS driver.

    >>
    >>
    >> You introduced the possibility that there were exceptions, yourself,
    >> earlier in the thread; I was just caveating what I wrote to cater for
    >> that.
    >>
    >>> All others do not increase the poll interval under any circumstances.

    >>
    >>
    >> Yes. That's how I read the code; however Heiko appears to have
    >> empirical evidence to the contrary. (One thought I had is that there
    >> seems to be more than one state variable involved and maybe ntpq peers
    >> doesn't show the actual poll interval)
    >>
    >>> Second, there is no failover at all. The design is that more than one

    >>
    >>
    >> I suspect failover is concept that customers and salesmen like. I do
    >> try to stress that ntpd averages multiple sources (and the weighting
    >> isn't tied to the current system peer). One other aspect of that
    >> particular myth is the concept of clock hopping. I think clock
    >> hopping can only happen if you have enough clocks that the set of
    >> retained clocks changes. I'm sure a lot of people believe that ntpd
    >> only uses data from the current "system peer".
    >>
    >> One caveat, as I understand it, if they used a prefer keyword, ntpd
    >> would failover from that server to an average of all the others.
    >>
    >>> reference clock driver is happily supported at the same time. Their
    >>> contributions are continuously evaluated and mitigated, so there is
    >>> no delay in using one or the other or both. If the intended behavior
    >>> is to "fail over" in the usual sense of those words, you should be
    >>> using something other than NTP>

    >>
    >>
    >> I think you meant Heiko should be.


+ Reply to Thread