[ntp:questions] ntp.conf true and prefer option for server command
Brian Inglis
Brian.Inglis at SystematicSw.ab.ca
Sun Jan 22 19:34:52 UTC 2017
On 2017-01-16 00:15, suhas manjunath wrote:
> I was trying to configure ntp servers in my ntp.conf file. Below is
> the snippet of conf file.
>
> restrict -4 IP1 kod nomodify notrap nopeer noquery
> server -4 IP1 prefer true iburst minpoll 4 maxpoll 6
>
> restrict -4 IP2 kod nomodify notrap nopeer noquery
> server -4 IP2 iburst minpoll 4 maxpoll 6
>
> restrict -4 IP3 kod nomodify notrap nopeer noquery
> server -4 IP3 iburst minpoll 4 maxpoll 6
>
> As per my understanding if prefer true option is used with IP1,
Options prefer and true are distinct options.
> it'll escape/survive select and cluster algorithm, and will always be
> selected as preferred server but it is not working it is taking IP3
> as a preferred server. Could anyone please explain it why?
Sources marked true are passed by the select process;
sources marked prefer may be discarded by the select process;
sources marked true or prefer may be discarded by the cluster process;
sources marked prefer reaching the combine process will be selected
as the system source and their offset and jitter used as the system
values used to discipline the system clock.
> Also to add more info: if I delete IP2 and IP3 forwarder then it will
> take IP1 has preferred forwarder.
They are not forwarders, they are servers: each is subject to its own
discipline, will develop its own idea of UTC with its own error bounds,
and provide that to clients choosing them as sources, which process adds
its own errors due to network and processing delays, which the client
handles with its own processing, developing its own idea of UTC with its
own error bounds.
If you only have one source, the client will treat it as a truechimer,
even if its time is off by days!
You always need more than two sources, preferably odd numbers of
sources, so that n/2 can be off, bad, or unavailable, and the
truechimers can still outvote the falsetickers with a strict majority
clique.
> Output of ntpq –pn:
> # ntpq -pn
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> IP1 IP4 5 u 1 64 377 0.337 -14.852 0.913
> +IP2 LOCAL(0) 7 u 55 64 377 0.290 0.224 1.286
> *IP3 IP5 4 u 65 64 377 159.282 -13.244 1.914
> 127.127.1.2 .LOCL. 10 u 1969 16 0 0.000 0.000 0.000
Drop the local clock, it will only be believed if you lose all other
sources, and will have nothing to discipline it, same as if NTP was not
running.
Drop IP2 using its local clock with no discipline, and any others like it.
If you can not use network sources, run your servers in orphan mode, so
they agree with each other, but never consider, rely on, or use the time
provided as anything related to UTC or any other consistent time scale!
It's your own local undiscplined reference time, with random variations
in time periods due to your servers' low quality hardware clocks.
Orphan mode should really only be set up for use as a backup when no
reference or network sources are available due to outages.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
More information about the questions
mailing list