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

Terje Mathisen terje.mathisen at tmsw.no
Tue Feb 24 14:22:43 UTC 2015


Markus Schöpflin wrote:
> 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.

You should probably update to 4.2.8, but I assume you are running the 
official versions from Oracle?
>
> 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.

OK.
>
> 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?

I know that the iburst behavior was modified slightly to avoid 
triggering the abuse detectors.
>
> 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.

Yeah, this is more or less as designed.
>
> 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?

It would be an interesting option to iburst to make it take effect after 
each clock reset, not just immediately after a restart, you could enter 
a feature request for this!

In the meantime, and particularly if you insist on running 5-10 year old 
versions, your dual startup of ntpd is probably your best bet:

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

You should not need the pid file for the first run since that one is 
stopping asap, and the -g is unneeded for the final instance since the 
clock has already been set. (If it hasn't and the clock is out by more 
than 1000 seconds, you probably want an alarm instead!)

This way you get the full iburst handling twice, which is exactly what 
you want. :-)

Terje
>
> Markus


-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



More information about the questions mailing list