[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