[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