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

Andrew Hood ajhood at fl.net.oz
Fri Oct 17 23:30:51 UTC 2003

On Sat, 18 Oct 2003 00:29:16 +1000, Eric wrote:

> On Fri, 17 Oct 2003 21:09:21 +0900, Yuji Hoshino
> <yuji.hoshino at niscom.co.jp> wrote:
>>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 .
>>Why does "synchronisation lost" occur after "time reset" ,
>>in which there is almost no time difference ?
>>What is the reason why "synchronisation lost" happens ?
>>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
> The messages are IMO out of order, but it doesn't really matter.

They are in order.

>                                                                  They
> occur in pairs, sync lost & time reset.  The NTPD process continually
> keeps the local clock synchronized to the upstream servers.  The
> specification requires that the local clock always be with 128ms of
> the calculated correct time.  When the polls to the upstream servers
> give misleading times (because of asymmetric delays, for example), the
> calculated time may suddenly appear to be more than 128ms off from the
> local clock, and at that point, NTPD "knows" two things: 1) the local
> clock is very wrong, which should not have happened, so sync is now
> officially lost, and 

At this point sync is still present. The clocks are now too far apart for
slew to be effective, so

>                      2) If options permit, the time will be stepped
> rather than slewed to allow the local clock to be more correct,
> sooner.    

Which causes sync to be lost.

> After the network congestion or trouble that led to the asymmetric
> delays goes away, NTPD often hits the same problem in reverse, because
> it has now stepped the local time based on inaccurate poll times, and
> the current polls show that calculated time to be way off, in the
> other direction, so sync has now been lost again, and the local clock
> is re-stepped to correct it, and is probably now close to where it
> started.  This seems to fit with your example above.
> - Eric


Avoid reality at all costs.
$email =~ s/oz$/au/o;

More information about the questions mailing list