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" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> >>> Maarten Wiltink wrote: >>> >>>> "David Woolley" <[EMAIL PROTECTED]> wrote in message >>>> news:[EMAIL PROTECTED] >> >> >>>>> 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 >> >> _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions