Is there any way to make ntpd to iteratively consult the server addresses given in the ntp.conf file?

Question

Suppose the machine has an ntp.conf file that looks like this:

driftfile <path-to-drift-file>
server <NTP-server-1>
server <NTP-server-2>
server <NTP-server-2>

For some reason, let us say that the NTP server is not running at the first query to all servers. Can we make ntpd reiterate querying these sources (i.e. again consult server-1 to server-3 in a loop)? How do we do it?

Edit: Is there any way to quantitatively determine which server caused the actual time sync from the list of servers given in the ntp.conf in the machine?

Answer 1

All defined servers in /etc/ntp.conf are used to synchronize time. There's no need to have it "loop" through the servers as the algorithm already handles multiple sources.

The ntpd program operates by exchanging messages with one or more configured servers at designated poll intervals.

From: man ntpd

You can see this by executing ntpq -p on the command-line to show your peers and their status.

You might see output like shown here:

  remote           refid      st when poll reach   delay  offset    disp
========================================================================
+128.4.2.6    132.249.16.1     2  131  256  373     9.89   16.28   23.25
*128.4.1.20   .WWVB.           1  137  256  377   280.62   21.74   20.23
-128.8.2.88   128.8.10.1       2   49  128  376   294.14    5.94   17.47
+128.4.2.17   .WWVB.           1  173  256  377   279.95   20.56   16.40

The output is explained in the man pages, too. But, over time I collected some notes:

remote: peers specified in the ntp.conf file
* = current time source
# = source selected, distance exceeds maximum value
o = source selected, Pulse Per Second (PPS) used
+ = source selected, included in final set
x = source false ticker
. = source selected from end of candidate list
- = source discarded by cluster algorithm
blank = source discarded high stratum, failed sanity

refid: remote source’s synchronization source

stratum: stratum level of the source

t: types available
l = local (such as a GPS, WWVB)
u = unicast (most common)
m = multicast
b = broadcast
- = netaddr

when: number of seconds passed since last response

poll: polling interval, in seconds, for source

reach: indicates success/failure to reach source, 377 all attempts successful

delay: indicates the round trip time, in milliseconds, to receive a reply

offset: indicates the time difference, in milliseconds, between the client server and source

disp/jitter: indicates the difference, in milliseconds, between two samples

Finally, to answer the last question;

Is there any way to quantitatively determine which server caused the actual time sync from the list of servers given in the ntp.conf in the machine?

The host indicated with the (*) is your currently selected time source. This can change during polling.

Answer 2

Ntpd will, at startup, query all configured server and pick the one with the lowest stratum. If that one fails, it will automatically fall over to the next server. So why would you want to change that?

Wikipedia: Network Time Protocol - Clock strata

Edit: After checking around I found some information about the iburst parameter, which is actually intended to speed up the clock-synchronization. The difference here is, that it will make the ntpd-server to exit when it can't reach any of the server. You could abuse this in a way to make sure that an instance of ntpd is running at all times, for instance by using a watchdog or a simple script ran by cron every now and then.

Unfortunately I couldn't figure out what the default behaviour of ntpd is when no server is reachable; although I found a lot of references about how it will behave when the servers don't resolve in DNS (e.g. this bug) or when the interface goes down.