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

Markus Schöpflin no.spam at spam.spam
Tue Feb 24 15:11:58 UTC 2015


Am 24.02.2015 um 15:22 schrieb Terje Mathisen:
> 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?

Yes, this is the official version from Oracle.

I think I could justify an update to a private build when it actually helps, 
but not otherwise. I will check using the latest release if the behaviour is 
any different.

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

It is still documented as sending a burst of 8 packets here: 
http://doc.ntp.org/4.2.6p5/confopt.html.

I think it is correctly described here: 
http://www.eecis.udel.edu/~mills/ntp/html/poll.html.

>> 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!

I'm not sure if it's not a bug that iburst doesn't take effect after the clock 
reset, as ntpd seems to consider the server as unreachable after performing 
the reset.

The following excerpt of the log file makes me think so (this is from after 
the reset of the local clock):

report_event: system event 'event_clock_reset' (0x05) status 'sync_alarm, 
sync_unspec, 3 events, event_peer/strat_chg' (0xc034)
transmit: at 34 <client> -> <server 1> mode 3
receive: at 34 <server 1> <- <client> mode 4 code 1 auth 0
peer <server 1> event 'event_reach' (0x84) status 'unreach, conf, 2 events, 
event_reach' (0x8024)
clock_filter: n 1 off 0.000022 del 0.000214 dsp 7.937508 jit 0.000000, age 0

Note the status 'unreach' in the event report for 'event_reach'.

> 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!)

Thanks for the suggestion, and yes, the system should not start when the 
second call to ntpd doesn't succeed without -g.

BTW, I don't insist on actually using an old version of NTPD, but we try to 
avoid using private RPM builds whenever possible.

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

Thank you very much for your comments.

Markus



More information about the questions mailing list