[ntp:questions] NTP not synchronizing to server

Per Hedeland per at hedeland.org
Mon Jan 8 07:17:12 UTC 2007

In article <UOOdnWRkpt0G5jzYnZ2dnUVZ_sWdnZ2d at comcast.com> "Richard
B. Gilbert" <rgilbert88 at comcast.net> writes:
>Per Hedeland wrote:
>> I.e. in general, it works just fine to use NTP to synchronize against a
>> server that only has its local clock as reference (the quality of the
>> time is another thing) - according to the docs it's even "the intended
>> use" for the LOCAL refclock, and of course it's quite commonly done. The
>> problem here is with the server (non-)implementation.

>I was under the impression that serving the local clock was intended to 
>provide a few hours of "holdover" if the connection to upstream servers 
>is lost.

No need to be under an impression, just read the docs:-) - that's #2 of
the given reasons to use the local refclock. It's probably also the most
common use case and (in the cases where it's meaningful at all, see
Harlan's post - unfortunately as can be seen from posts here, it's often
used in other cases too) the most "reasonable" one.

>  If the local clock has been disciplined by ntpd it should have 
>both a correct time and a proper frequency correction that will allow it 
>to carry on for a few hours.  How long the time will remain reasonably 
>correct would depend on the quality of the local clock, variations in 
>the temperature inside the computer case, etc.

All true - note that I wasn't arguing the goodness of using the local
refclock, just that clients of a server using it have no way of knowing
whether it has correct time or proper frequency correction, and hence
can't use such things to determine whether they will "believe" that
server (unless they are using other servers too, of course - but that
wasn't the case here).

>ISTR that David Mills added an "Orphan Mode" to ntpd a year or so ago 
>that's intended for use on isolated networks that lack a reference clock 
>other than the local clock of some computer.  I've never needed it so 
>I'm not familiar with how to set it up or exactly how it differs from 
>simply serving the undisciplined local clock.

I'm not familiar with it either, but gather that its main advantage is
that it avoids the need to play semi-reliable tricks with artificial
stratum values when you have *multiple* servers that may play the role
of "master" on such a network, but still need/want all hosts to have the
same time.

--Per Hedeland
per at hedeland.org

More information about the questions mailing list