[ntp:questions] How to best speed up synchronisation after system reboot?

Markus Schöpflin no.spam at spam.spam
Tue Feb 24 13:05:12 UTC 2015


First some background information:

The following behaviour has been observed on a HP ProLiant DL360 G7 running 
Oracle Linux Server release 6.3 and ntp 4.2.4p8.

The following ntpd configuration is used, ntp servers are all local stratum 1 
dedicated servers.

driftfile /var/lib/ntp/drift
server ntp1 version 4 iburst minpoll 5 maxpoll 5 prefer
server ntp2 version 4 iburst minpoll 5 maxpoll 5
server ntp3 version 4 iburst minpoll 5 maxpoll 5
peer peer1 version 4 iburst minpoll 5 maxpoll 5

Ntpd is running with the following command line:

   ntpd -u ntp:ntp -p /var/run/ntpd.pid -g

We have an application running on the client which needs a synchronised time. 
  The application is only started once NTPD reports that the local clock is 
synchronised and the offset within 300ms. For safety reasons, the application 
is terminated when NTPD reports an offset larger than 300ms.

Now the actual problem description:

To speed up initial synchronisation after a system reboot, we are using 
iburst. According to the documentation, using iburst is supposed to send a 
burst of eight packets when the server is unreachable.

This seems to be untrue, I only ever observed four packets to be sent. The 
observed behaviour more looks like it can send up to eight packets, but stops 
as soon as it is synchronised to a server.

Is the documentation incorrect here?

NTPD reports a successful synchronisation about 7 seconds after it starts, 
which is pretty good.

But quite frequently the system clock is off more than 128ms after a reboot, 
causing NTPD to perform a clock reset immediately after becoming synchronised 
and again report the clock as unsynchronised. This reset also seems to entail 
throwing away all available data samples in the clock filter.

Only about three times the fixed poll interval of 32s later the clock is again 
reported as synchronised.

I have experimented with running ntpdate (or ntpd -g -q) once before starting 
ntpd which indeed helps as it brings the system time close enough to the 
correct time to avoid the clock reset when ntpd is started as a daemon, but 
according to http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate ntpdate is 
deprecated and anyway it shouldn't be needed to be run before starting ntpd, 
so this maybe isn't the best solution.

So is there some way to speed up the second waiting period (after the clock 
reset) using a suitable configuration for NTPD? Or can NTPD be configured to 
also send a burst of packets after the clock has been reset?

Markus



More information about the questions mailing list