prefer keyword and server failover
Andrew Stone
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
David Woolley
>
> I would like to configure my ntp client to use 2 servers only. I want
+ 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.
Richard B. Gilbert
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!
Steve Kostecke
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 <kost...@ntp.org>
NTP Public Services Project - http://support.ntp.org/
David Woolley
>
> 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.
Danny Mayer
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
Danny Mayer
> 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
David Woolley
> 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).
Danny Mayer
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
David L. Mills
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
David Woolley
> 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.)
David L. Mills
See the documention on the true option of the server command. Compare
with the prefer and noselect options.
Dave
David Woolley
>
> 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".
David Woolley
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 \<true\>, 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.
David L. Mills
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