[ntp:questions] Re: Q:About "Time reset & Sync Lost"

Frederick Bruckman fredb at immanent.net
Sat Oct 18 01:43:58 UTC 2003

In article <mailman.40.1066392577.1751.questions at ntp.org>,
	Yuji Hoshino <yuji.hoshino at niscom.co.jp> writes:
> I want to know the relation of "Time reset & Sync Lost".
> I checked the ntp log .
> -------------------------------------------------
> 8 Oct 22:03:52 ntpd[777]: time reset 0.217715 s
> 8 Oct 22:03:52 ntpd[777]: synchronisation lost
> 8 Oct 22:19:45 ntpd[777]: time reset -0.305509 s
> 8 Oct 22:19:45 ntpd[777]: synchronisation lost
> -------------------------------------------------
> I understand that "time reset" means setting the clock
> not gradually,but immediately.
> (when "offset" value is more than 128 ms)
> But after "time reset","synchronisation lost" always occurs.
> I think that the clock has been set correctly after "time reset"
> and that an ntp server is in synchronisation because there is
> almost no time difference .

There's more to synchronisation than merely being set to the
correct time. The phase-locked loop has to be happy, too, which
means the frequency has to be close enough so that small changes
in phase can "lock in" the loop.
> Why does "synchronisation lost" occur after "time reset" ,
> in which there is almost no time difference ?

Simply put, because the clock *frequency* has been brought into

> What is the reason why "synchronisation lost" happens ?

You example is typical. Notice that there's two steps just about
fifteen minutes apart. The first reset was due to a "spike". That
is, a packet correlated well enough with recent packets, yet even
so, indicated a correction greater than the _step_ threshold (which
defaults to 0.128s).

This means something is really wrong. The daemon responds be stepping
the clock, recalculating the frequency, resetting the phase to zero,
declaring the clock unsynchronized, *and* switching into frequency mode.
In frequency mode, the peers are polled as usual, but no tweaks to the
phase are made. The first good packet after the _stepout_ threshold
(default 900s) steps again if necessary, sets the frequency based on
the drift over the time spent in frequency mode, and again resets the
phase to zero.

Hopefully, after this second step, not only is the time correct, but
the frequency is close, too, and the PLL can lock in quickly. If not,
the daemon will do the "spike" thing again, and go back into frequency
mode, again.

Observe that in your example, as is often the case, the spike correction
was bogus, and was essentially reverted by the subsequent frequency mode


More information about the questions mailing list