[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