[ntp:questions] Re: What can be uses as an SNTP server
Richard B. Gilbert
rgilbert88 at comcast.net
Mon Jun 13 13:01:54 UTC 2005
David L. Mills wrote:
> Good comments. As you know, a primary server operating at stratum 1
> displays the source in the reference ID field, with the expectation
> that an unsynchronized local clock shows something like LOCL. The
> problem is how to detect this condition with a higher local clock
> stratum assignment. An obvious way to do this is to require that the
> reference ID be the local clock driver itself. This makes it easy for
> the immediate upstratum client to discover the local clock, but
> disguises it for its own upstratum clients.
> I am a little concerned about the overuse of local clock "subnets"
> with multiple local clocks arranged in a fallback configuration. There
> have been reports where some failure or other resulted in nasty timing
> loops and counting to infinity behavior.
> If the local clock is intended as fallback when all synchronized
> sources are lost, the best response in most configurations is for all
> clients simply to coast with no sources. With the ACTS driver and a
> poll interval of 36 hours, the residual offset rarely exceeds 20 ms.
> So why bother with a local clock if the MTTR is less than a day? Let
> the dependents coast until the synchronized sources are found again.
> If the local clock is by design the only source in the subnet and
> there is no opportunity to find synchronized sources, then operate the
> local clock server at stratum 1 and be done with it.
> Richard B. Gilbert wrote:
>> David Woolley wrote:
>>> In article <ywn9d5qs9vil.fsf at ntp1.isc.org>,
>>> Harlan Stenn <stenn at ntp.isc.org> wrote:
>>>> I just re-read the draft 2030 spec and it says that the legal
>>>> values for
I thought that the concern with unsynchronized local clocks on an
isolated net operating at a low stratum was that the isolation might not
A high stratum should be plenty of warning if such a system did get
connected to the internet.
Some subnets are isolated because there is no internet connection
available, some because a connection to the internet is forbidden for
security reasons and perhaps there might be other reasons. I think that
all of the above are subject to change with varying probabilities of
such a change.
I think that any new RFC for NTP should specify a safe way (for the rest
of the world) to set up such an isolated net. It should, of course,
include appropriate warnings about the limitations of such a setup and
the suggestion the NTP might be the wrong tool for the job. (All right,
it IS the wrong tool but people want their clocks synchronized and
don't really care what time it is and NTP is there. . . . There's no
point in fighting a battle already lost.)
More information about the questions