[ntp:questions] Re: What can be uses as an SNTP server

David L. Mills mills at udel.edu
Sun Jun 12 16:31:04 UTC 2005


Richard,

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.

Dave

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
>>>   
>>
>>
>> RFC 2030 is released.  It can't be a draft.  Any replacement will have
>> a new RFC number.  It will either obsolete RFC 2030 or define a new 
>> version
>> of the protocol.  (For example, the NTP v4 RFC, when it arrives, will not
>> obsolete RFC 1305.)
>>
>>  
>>
>> <snip>
>>
>>
>> You may be proposing a new RFC.  In that case, I doubt that you can 
>> change
>> a SHOULD NOT into a MUST NOT without creating a new version of the 
>> protocol,
>> as I very much doubt that IETF likes retrospective legislation.  To get
>> your desired effect in a new version of the protocol, you would need 
>> to have something like:
>>
>>   1        primary reference (this value SHALL only be used by
>>            <definition that doesn't depend on the use of "e.g.">)
>>   2-15     secondary reference (these values SHALL only be used by
>>            a server fully implementing NTP (RFCxxxx))
>>  
>>
> That seems to me to be entirely too many strata!   Since each stratum 
> degrades the quality of time; sometimes significantly, stratum 14 would 
> likely be no better than your great grandfather's tall case clock 
> (commonly called a grandfather clock).
> 
> Stratum ten is "conventional" for an unsynchronized local clock because 
> nobody is likely to listen to or believe a server claiming stratum ten 
> if there is any other choice.
> 
> Is anybody synchronizing anything to a stratum higher than five or six?  
> (other than servers running unsynchronized local clocks?)
> 
> I've read elsewhere that stratum is an eight bit field.  It seems to me 
> that five of those bits might be dedicated to some more useful purpose; 
> e.g. indicating a sever using SNTP, a server using an unsynchronized 
> local clock, a secondary server with fewer than four upstream sources, etc.
> 
> Some of the bits might be used to indicate the type of reference clock 
> since some are much more desirable than others; e.g. a server 
> synchronized to GPS at stratum 1 is more desirable than a server 
> synchronized to an HF radio clock at stratum one.



More information about the questions mailing list