[ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?

David Woolley david at ex.djwhome.demon.co.uk.invalid
Wed Mar 12 22:02:27 UTC 2008

David L. Mills wrote:
> Maartin and others,
> The intended model for monitoring and control is clearly articulated in 
> the control and monitoring protocol defined in rfc 1305. This model 

I can't speak for Maartin, but I was talking about the operation of the 
protocol itself.  The values in question are needed to correctly 
construct a server response packet, so, it you split client and server, 
you must communicate this information between them.

> provides status words and event codes explicitly designed for remote 
> access and as a demarcation between the idiosyncratic inner workings of 
> the implementation and the external view. This and the NTP packet itself 
> is the only intended external view of the running program. Anything else 
> is speculation and subject to change, specifically the details other 
> than the status words, events and fixed configuration information on the 
> ntpq billboards.
> The intent of the original design which continues today is that a small 
> perl script can be used to query ntpd, parse the codes and traps and 
> either beep the administrator or respond as an SNMP agent. We did that 
> some years ago as a concept test and it worked fine, but the old rickety 
> code has neen lost to antiquity. That project should be relaunched by a 
> competent perlman.
> The code has been recently audited to be sure the status words and event 
> codes are aligned to the current implentation. A few small adjustments 
> have been made to align small differences that have accumulated since 
> 1992. The codes and events are summarized in the current web documentation.
> Having said this, folks will continue to pry the details other than the 
> above from the ntpq billboards. Those details specifically called out in 
> the NTPv4 specirication will continue as advertised, but the specific 
> text names are not guaranteed. They are intended for eyeball, not 
> machine decode. Those not called out in the specification are subject to 
> change, either in name or function or both.
> Dave
> Maarten Wiltink wrote:
>> "David Woolley" <david at ex.djwhome.demon.co.uk.invalid> wrote in message
>> news:47d79152$0$508$5a6aecb4 at news.aaisp.net.uk...
>>> Maarten Wiltink wrote:
>>>> "David Woolley" <david at ex.djwhome.demon.co.uk.invalid> wrote in message
>>>> news:47d70081$0$510$5a6aecb4 at news.aaisp.net.uk...
>>>>> stratum
>>>>> root distance
>>>>> root dispersion
>>>>> system peer
>>>>> local reference time
>>>>> leap bits
>>>>> etc.
>>>> Yes. Those are all client-part statistics that could easily be made
>>>> available to a server-part for dishing out to anyone interested in
>>>> evaluating the status and quality indicators of your server. ...
>>> These things are needed for the core protocol.  You cannot act as a
>>> valid server to even the most primitive of valid clients without them.
>>> They are not diagnostic information for ntpq, they are needed to
>>> construct a valid server packet.
>> Not all statistics are diagnostics. Some are, as you say, core.
>>> Without them you don't even have a compliant SNTP server; you
>>> basically have an RDATE like server with sub-second resolution.
>> An SNTP or local clock server might have to make some of them up.
>> System peer? Root dispersion?
>> Groetjes,
>> Maarten Wiltink

More information about the questions mailing list