[ntp:questions] long time to report sync per leap indicator, when initial system time is set far into the future
martin.burnicki at burnicki.net
Wed Dec 13 11:58:15 UTC 2017
Mike Cook wrote:
>> Le 12 déc. 2017 à 17:31, Stephan E. <public-se at innominate.com> a écrit :
>> During that waiting period, I get a status of e.g.
>> # ./ntpq -c peers
>> remote refid st t when poll reach delay offset jitter
>> ptbtime1.ptb.de .STEP. 16 u - 64 0 0.000 0.000 0.000
>> ptbtime2.ptb.de .STEP. 16 u 20 64 0 0.000 0.000 0.000
>> ptbtime3.ptb.de .STEP. 16 u 25 64 0 0.000 0.000 0.000
>> ntp2.m-online.n .STEP. 16 u 770 64 0 0.000 0.000 0.000
>> 1c.ncomputers.o .STEP. 16 u 385 64 0 0.000 0.000 0.000
>> ntp1.wtnet.de .STEP. 16 u 850 64 0 0.000 0.000 0.000
>> backup.heikoric .STEP. 16 u 1864 64 0 0.000 0.000 0.000
>> # ./ntpq -c rl
>> associd=0 status=c018 leap_alarm, sync_unspec, 1 event, no_sys_peer,
>> version="ntpd 4.2.8p10 at 1.3728-o Tue Dec 12 11:03:31 UTC 2017 (1)",
>> processor="ppc", system="Linux/3.10.104", leap=11,
>> stratum=16, precision=-18, rootdelay=0.000, rootdisp=1.620, refid=STEP,
>> reftime=00000000.00000000 Thu, Feb 7 2036 6:28:16.000,
>> clock=ddda50cf.3c52fb54 Tue, Dec 12 2017 12:57:51.235, peer=0, tc=6,
>> mintc=3, offset=0.000000, frequency=0.000, sys_jitter=0.003815,
>> clk_jitter=0.004, clk_wander=0.000
> This confirms what I found. The reason that you are not getting any responses from the servers is not clear. Once I had defined 3 or 4 servers I had no issues.
Hm, the refids are all 'step', so this sounds like the servers could be
contacted, a large time offset was determined, and then the system time
was indeed stepped to be adjusted.
The "processor" string above is "ppc": Is it possible that the system
timing is messed up on this system in a way that ntpd waits for a looong
time after the step (instead of just the poll interval time) before it
sends its next requests to the server?
Running tcpdump should show if this is the case.
That would explain why ntpd synchronizes after about ~24 hours if a ~24
hour time offset has been adjusted, so it waits ~24h+64s before it polls
the servers next time after the step.
This would also explain why ntpd synchronizes immediately if it is
restarted after the time has been stepped.
Of course a workaround would be to run ntpdate first (or ntpd -gq, which
also terminates after the time has been stepped), and then start ntpd
for continuous operation. However, normally this should also work with
If the timing is really messed up this is a flaw, and it would be
interesting to know why this happens (on this platform?).
Starting ntpd with debug on the console could give some hints.
More information about the questions