prefer keyword and server failover - NTP

This is a discussion on prefer keyword and server failover - NTP ; Hi all, I would like to configure my ntp client to use 2 servers only. I want it to receive updates from only one of them, but then use the other when that one fails. What is the best way ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: prefer keyword and server failover

  1. prefer keyword and server failover

    Hi all,

    I would like to configure my ntp client to use 2 servers only. I want it to receive updates from only one of them, but then use the other when that one fails. What is the best way to do this? Will setting the primary server to use the 'prefer' keyword work?

    Thanks,
    Andrew

  2. Re: prefer keyword and server failover

    Andrew Stone wrote:
    >
    > I would like to configure my ntp client to use 2 servers only. I want

    + it to receive updates from only one of them, but then use the other when
    + that one fails. What is the best way to do this? Will setting the
    + primary server to use the 'prefer' keyword work?

    I'm not 100% sure, but I think that the two clocks need to be mutually
    truechimers, otherwise both may get rejected, as prefer only seems to be
    applied after the falsetickers are excluded.

    That *shouldn't* be a problem, but then your requirement shouldn't be
    needed, either, so I wonder if one or both of the time sources isn't a
    truechimer.

    Knowing what is wrong with the second time source would help people to
    make sensible suggestions.

    Note that, in normal configurations, ntpd uses a weighted average of
    several truechimers, certainly at least two of them.

  3. Re: prefer keyword and server failover

    Andrew Stone wrote:
    > Hi all,
    >
    > I would like to configure my ntp client to use 2 servers only. I want it to receive
    >updates from only one of them, but then use the other when that one fails. What is the
    >best way to do this? Will setting the primary server to use the 'prefer' keyword work?
    >


    Sort of! Two servers is generally a poor choice. If they differ, as
    they inevitably will, which one should you believe? 'Prefer' will tell
    your client which one to believe but with a couple more servers ntpd
    should be able to figure out which one is closest to being correct!


  4. Re: prefer keyword and server failover

    On 2008-04-25, Andrew Stone wrote:

    > I would like to configure my ntp client to use 2 servers only. I want
    > it to receive updates from only one of them, but then use the other
    > when that one fails. What is the best way to do this? Will setting the
    > primary server to use the 'prefer' keyword work?


    Try it and see what happens.

    Another way to handle this is to configure your secondary server to use
    your primary as a source.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  5. Re: prefer keyword and server failover

    Richard B. Gilbert wrote:

    >
    > Sort of! Two servers is generally a poor choice. If they differ, as
    > they inevitably will, which one should you believe? 'Prefer' will tell


    If they differ enough for voting to apply, both will be rejected. If
    they are mutually true chimers and you don't use prefer, ntpd will use a
    combination of the time from both of them.

    > your client which one to believe but with a couple more servers ntpd
    > should be able to figure out which one is closest to being correct!
    >


  6. Re: prefer keyword and server failover

    Andrew Stone wrote:
    > Hi all,
    >
    > I would like to configure my ntp client to use 2 servers only. I want
    > it to receive updates from only one of them, but then use the other when

    that one fails. What is the best way to do this? Will setting the
    primary server to use the 'prefer' keyword work?

    You totally misunderstand the way that NTP works. Having multiple
    servers is not meant as a load-balancing or failover mechanism, it meant
    to be used to find the best and most reliable NTP server over any period
    and to switch as necessary when the currently chosen server has become
    worse (whether accuracy, precision, delay or other reasons) than other
    servers in the list. Failover is purely automatic and you are unlikely
    to ever notice. Two servers is the worst option since it will be unable
    to decide which one is better (usually). Three is the minimum
    recommended and four is preferred. You do *not* normally need to worry
    about additional NTP packets being sent to the servers, they barely
    notice the extra load, unless it's one the heavily loaded public servers
    such as the ones run by NIST.

    Danny

  7. Re: prefer keyword and server failover

    David Woolley wrote:
    > Richard B. Gilbert wrote:
    >
    >> Sort of! Two servers is generally a poor choice. If they differ, as
    >> they inevitably will, which one should you believe? 'Prefer' will tell

    >
    > If they differ enough for voting to apply, both will be rejected. If
    > they are mutually true chimers and you don't use prefer, ntpd will use a
    > combination of the time from both of them.
    >


    No, it will choose one and use it until it decides that it is worse than
    another one or they are all declared bad. It never combines both. The
    real problem here is that it has no idea whether or not one is better
    than the other when you only have two of them.

    Danny

    >> your client which one to believe but with a couple more servers ntpd
    >> should be able to figure out which one is closest to being correct!


  8. Re: prefer keyword and server failover

    Danny Mayer wrote:
    > David Woolley wrote:
    >> Richard B. Gilbert wrote:
    >>
    >>> Sort of! Two servers is generally a poor choice. If they differ, as
    >>> they inevitably will, which one should you believe? 'Prefer' will tell

    >> If they differ enough for voting to apply, both will be rejected. If
    >> they are mutually true chimers and you don't use prefer, ntpd will use a
    >> combination of the time from both of them.
    >>

    >
    > No, it will choose one and use it until it decides that it is worse than
    > another one or they are all declared bad. It never combines both. The
    > real problem here is that it has no idea whether or not one is better
    > than the other when you only have two of them.


    For RFC 1305, and I have no reason to believe this has changed, given m
    servers that pass the basic sanity check, it will start with another
    parameter, f, at 0 and try to find m -f intersecting servers. It will
    try with successively greater values of f until it finds a mutually
    intersecting set of servers. However, if f equals or exceeds m/2, it
    will stop with all servers marked as falsetickers. m/2 = 1 in this
    case, so the termination condition will be met after one iteration, and
    it will fail to find any truechimers (the low end of the range will be
    set to the low end of the second server tolerance (search is done
    forwards) and the high end of the range will be set to the high end of
    the first (search is done backwards).

  9. Re: prefer keyword and server failover

    David Woolley wrote:
    > Danny Mayer wrote:
    >> David Woolley wrote:
    >>> Richard B. Gilbert wrote:
    >>>
    >>>> Sort of! Two servers is generally a poor choice. If they differ, as
    >>>> they inevitably will, which one should you believe? 'Prefer' will tell
    >>> If they differ enough for voting to apply, both will be rejected. If
    >>> they are mutually true chimers and you don't use prefer, ntpd will use a
    >>> combination of the time from both of them.
    >>>

    >> No, it will choose one and use it until it decides that it is worse than
    >> another one or they are all declared bad. It never combines both. The
    >> real problem here is that it has no idea whether or not one is better
    >> than the other when you only have two of them.

    >
    > For RFC 1305, and I have no reason to believe this has changed, given m
    > servers that pass the basic sanity check, it will start with another
    > parameter, f, at 0 and try to find m -f intersecting servers. It will
    > try with successively greater values of f until it finds a mutually
    > intersecting set of servers. However, if f equals or exceeds m/2, it
    > will stop with all servers marked as falsetickers. m/2 = 1 in this
    > case, so the termination condition will be met after one iteration, and
    > it will fail to find any truechimers (the low end of the range will be
    > set to the low end of the second server tolerance (search is done
    > forwards) and the high end of the range will be set to the high end of
    > the first (search is done backwards).


    It has changed. RFC 1305 describes NTPv3. You need to see Section 11.2
    of the NTPv4 draft for the current selection algorithms. Particularly:

    > If the selection
    > algorithm cannot produce a majority clique, or if it cannot produce
    > at least CMIN survivors, the system process exits without
    > disciplining the system clock. If successful, the cluster algorithm
    > selects the statistically best candidate as the system peer and its
    > variables are inherited as the system variables.


    CMIN is currently 1. Notice that it says nothing about using more than one.

    Danny

  10. Re: prefer keyword and server failover

    Danny,

    To be fair, the basic selection algorithm has not changed from rfc1305,
    although the root distance metric and error budget have changed due to
    the much more precise clocks of today. It remains true that two sources
    with nonintersecting correctness intervals results in no source at all.

    What is different is the adjustable tos parameters minclock, maxclock,
    minsane and other tinkerables. The minsane parameter is the minimum
    number of sources required for correct synchronization. It really should
    be equal to the minimum number of survivors minclock (3). It defaults to
    one only because most people would consider otherwise a violation of the
    principle of least astonishment.

    Dave

    Danny Mayer wrote:
    > David Woolley wrote:
    >
    >>Danny Mayer wrote:
    >>
    >>>David Woolley wrote:
    >>>
    >>>>Richard B. Gilbert wrote:
    >>>>
    >>>>
    >>>>>Sort of! Two servers is generally a poor choice. If they differ, as
    >>>>>they inevitably will, which one should you believe? 'Prefer' will tell
    >>>>
    >>>>If they differ enough for voting to apply, both will be rejected. If
    >>>>they are mutually true chimers and you don't use prefer, ntpd will use a
    >>>>combination of the time from both of them.
    >>>>
    >>>
    >>>No, it will choose one and use it until it decides that it is worse than
    >>>another one or they are all declared bad. It never combines both. The
    >>>real problem here is that it has no idea whether or not one is better
    >>>than the other when you only have two of them.

    >>
    >>For RFC 1305, and I have no reason to believe this has changed, given m
    >> servers that pass the basic sanity check, it will start with another
    >>parameter, f, at 0 and try to find m -f intersecting servers. It will
    >>try with successively greater values of f until it finds a mutually
    >>intersecting set of servers. However, if f equals or exceeds m/2, it
    >>will stop with all servers marked as falsetickers. m/2 = 1 in this
    >>case, so the termination condition will be met after one iteration, and
    >>it will fail to find any truechimers (the low end of the range will be
    >>set to the low end of the second server tolerance (search is done
    >>forwards) and the high end of the range will be set to the high end of
    >>the first (search is done backwards).

    >
    >
    > It has changed. RFC 1305 describes NTPv3. You need to see Section 11.2
    > of the NTPv4 draft for the current selection algorithms. Particularly:
    >
    >
    >>If the selection
    >> algorithm cannot produce a majority clique, or if it cannot produce
    >> at least CMIN survivors, the system process exits without
    >> disciplining the system clock. If successful, the cluster algorithm
    >> selects the statistically best candidate as the system peer and its
    >> variables are inherited as the system variables.

    >
    >
    > CMIN is currently 1. Notice that it says nothing about using more than one.
    >
    > Danny


  11. Re: prefer keyword and server failover

    Danny Mayer wrote:

    > It has changed. RFC 1305 describes NTPv3. You need to see Section 11.2


    As far as I can see, the intersection algorithm hasn't changed.

    > of the NTPv4 draft for the current selection algorithms. Particularly:
    >
    >> If the selection
    >> algorithm cannot produce a majority clique, or if it cannot produce


    Note the "or" in the condition for rejecting everything; that's an "and"
    for not rejecting. The CMIN check is done, rather later, and only if
    the absolute majority check succeeds.

    As it happens, there is an undocumented option in the code of 4.2.4p4
    which allows one to force a peer to be a truechimer, even though it
    fails the intersection algorithm, but an ordinary users isn't going to
    find that option.

    >> at least CMIN survivors, the system process exits without
    >> disciplining the system clock. If successful, the cluster algorithm
    >> selects the statistically best candidate as the system peer and its
    >> variables are inherited as the system variables.

    >
    > CMIN is currently 1. Notice that it says nothing about using more than one.


    All that means is that if you only have one clock that passes sanity, it
    will be used. If you have two that pass sanity and they are
    incompatible, they will have been eliminated before it even gets to the
    CMIN test.

    I'll leave it to Dave Mills to volunteer the undocumented option, if he
    thinks it is safe to use in this application.

    (The use of orphan mode can also override the intersection algorithm.)

  12. Re: prefer keyword and server failover

    David,

    See the documention on the true option of the server command. Compare
    with the prefer and noselect options.

    Dave

    David Woolley wrote:
    > Danny Mayer wrote:
    >
    >> It has changed. RFC 1305 describes NTPv3. You need to see Section 11.2

    >
    >
    > As far as I can see, the intersection algorithm hasn't changed.
    >
    >> of the NTPv4 draft for the current selection algorithms. Particularly:
    >>
    >>> If the selection
    >>> algorithm cannot produce a majority clique, or if it cannot produce

    >
    >
    > Note the "or" in the condition for rejecting everything; that's an "and"
    > for not rejecting. The CMIN check is done, rather later, and only if
    > the absolute majority check succeeds.
    >
    > As it happens, there is an undocumented option in the code of 4.2.4p4
    > which allows one to force a peer to be a truechimer, even though it
    > fails the intersection algorithm, but an ordinary users isn't going to
    > find that option.
    >
    >>> at least CMIN survivors, the system process exits without
    >>> disciplining the system clock. If successful, the cluster algorithm
    >>> selects the statistically best candidate as the system peer and its
    >>> variables are inherited as the system variables.

    >>
    >>
    >> CMIN is currently 1. Notice that it says nothing about using more than
    >> one.

    >
    >
    > All that means is that if you only have one clock that passes sanity, it
    > will be used. If you have two that pass sanity and they are
    > incompatible, they will have been eliminated before it even gets to the
    > CMIN test.
    >
    > I'll leave it to Dave Mills to volunteer the undocumented option, if he
    > thinks it is safe to use in this application.
    >
    > (The use of orphan mode can also override the intersection algorithm.)


  13. Re: prefer keyword and server failover

    David L. Mills wrote:
    >
    > See the documention on the true option of the server command. Compare
    > with the prefer and noselect options.


    Where is it documented in 4.2.4p4. It is in the code, but the document
    (clockopt.html) that documents the other server options doesn't contain
    the word "true".

  14. Re: prefer keyword and server failover

    David Woolley wrote:
    > David L. Mills wrote:
    >>
    >> See the documention on the true option of the server command. Compare
    >> with the prefer and noselect options.

    >
    > Where is it documented in 4.2.4p4. It is in the code, but the document
    > (clockopt.html) that documents the other server options doesn't contain
    > the word "true".


    It turns out that it is documented in confopt.html, so I withdraw the
    suggestion that it is undocumented.

    One of the problems with HTML over man documentation is that one has to
    navigate the documentation structure to find the right file and it turns
    out that there are two files that document "server". I had to grep the
    directory for \, in the end, which wasn't helped by the very long
    lines in the HTML source.

    Actually, although confopt would have been the most relevent page for
    this thread, the description says its main intended use is for reference
    clocks, but it is not included/duplicated on the clockopt page, which is
    the page that one should be using for reference clocks (confopt doesn't
    document any strictly reference clock only parameters, but does
    duplicate some of the common ones).

    If one is going to go the hypertext route, I think one needs to go to a
    much more extreme level and have one file that gives a synopsis of every
    configuration file command without any description of the options, and a
    file for each option, hyperlinked from that option. That way the two
    server commands would be together and the text of the common options
    would always be the same.

    In this case I assumed that server would only be documented in one file,
    so didn't look closely enough to discover that that file only covered
    the server variant. That was complicated further because the server
    variant does fail to document a relevant option.


    You would need both true and prefer in this case, and a suitably recent
    version of ntpd.

  15. Re: prefer keyword and server failover

    David,

    As has been said many, many times, the documentation for the current
    version I maintain is on the web. Some of the features/hazards in the
    current version are not in the release version. The current
    documentation has a site map and command index which might lesson your
    pain; however, note that what man pages you might see are over my strong
    objection and may contain substantially incorrect information. The only
    true content, warts and all, is on the web pages. As per policy, the
    documentation for previous versions is in the distribution for that
    version. If it doesn't mention a particular feature, it is not available
    in that version.

    Dave

    David Woolley wrote:

    > David Woolley wrote:
    >
    >> David L. Mills wrote:
    >>
    >>>
    >>> See the documention on the true option of the server command. Compare
    >>> with the prefer and noselect options.

    >>
    >>
    >> Where is it documented in 4.2.4p4. It is in the code, but the
    >> document (clockopt.html) that documents the other server options
    >> doesn't contain the word "true".

    >
    >
    > It turns out that it is documented in confopt.html, so I withdraw the
    > suggestion that it is undocumented.
    >
    > One of the problems with HTML over man documentation is that one has to
    > navigate the documentation structure to find the right file and it turns
    > out that there are two files that document "server". I had to grep the
    > directory for \, in the end, which wasn't helped by the very long
    > lines in the HTML source.
    >
    > Actually, although confopt would have been the most relevent page for
    > this thread, the description says its main intended use is for reference
    > clocks, but it is not included/duplicated on the clockopt page, which is
    > the page that one should be using for reference clocks (confopt doesn't
    > document any strictly reference clock only parameters, but does
    > duplicate some of the common ones).
    >
    > If one is going to go the hypertext route, I think one needs to go to a
    > much more extreme level and have one file that gives a synopsis of every
    > configuration file command without any description of the options, and a
    > file for each option, hyperlinked from that option. That way the two
    > server commands would be together and the text of the common options
    > would always be the same.
    >
    > In this case I assumed that server would only be documented in one file,
    > so didn't look closely enough to discover that that file only covered
    > the server variant. That was complicated further because the server
    > variant does fail to document a relevant option.
    >
    >
    > You would need both true and prefer in this case, and a suitably recent
    > version of ntpd.


+ Reply to Thread