[ntp:questions] long time to report sync per leap indicator, when initial system time is set far into the future

Martin Burnicki 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 :
>>
>>
> 
> <snip>
> 
>> 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
just -g.

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.

Martin


More information about the questions mailing list