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

David L. Mills mills at udel.edu
Wed Mar 12 14:48:55 UTC 2008


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 
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