NTPv4 MIB Revised Version 1.2

Harlan,

I don't know why your level of enthusiasm is so high for
ntpdc. The 
ntpdc has inflexible binary packet headers, the data
representation is 
often wrong and the code is bloated and encrusted with
parnoid error 
checks. None of that is necessary with the standard mode-6
protocol 
(ntpq). Having said that, the bottom line is that ntpdc and
the mode-7 
protocol are private and thus not in the spec and not on the
agenda of 
this working group.

Dave

Harlan Stenn wrote:

> Dave sez:
>
>> I have strongly advised NOT using ntpdc as
monitoring probe. It has not
>> been properly maintained over the years and tells
many little lies
>> relative to the intended performance measures. The
only supoprted
>> article (at least by me) is ntpq, and this has been
carefully maintained
>> in proper display, scale and precision.
>
>
> We now have a maintainer for ntpdc and I expect that
ntpdc will be in
> decent shape within the next few months' time.
>
> I also expect that we will be able to evolve the
monitoring aspects of
> ntpd in a more generally useful way.
>
> The underlying problem with ntpdc is that it should
only be messing with
> mode 7 packets, which are by definition
implementation-specific. It
> will require some dilligence to make sure that future
versions of
> monitoring tools (ntpq and ntpdc) reliably report data
from older
> versions of the code.
>
> We had an example of this several months ago when the
internal state
> variables changed.
>
> H


_______________________________________________
ntpwg mailing list
ntpwglists.ntp.isc.org
http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg

David L. Mills wrote:
> Harlan,
> 
> I don't know why your level of enthusiasm is so high
for ntpdc. The
> ntpdc has inflexible binary packet headers, the data
representation is
> often wrong and the code is bloated and encrusted with
parnoid error
> checks. None of that is necessary with the standard
mode-6 protocol
> (ntpq). Having said that, the bottom line is that ntpdc
and the mode-7
> protocol are private and thus not in the spec and not
on the agenda of
> this working group.
> 
> Dave
>

I agree with Dave. Dealing with on-wire binary data is
fraught with
problems. Just defining what an on-wire floating point or
double
representation should look like and then having to write the
code to
translate between on-wire format and local format is just
not worth the
effort. You are talking about different formats on each
piece of
hardware and O/S. Don't go there.

Danny







_______________________________________________
ntpwg mailing list
ntpwglists.ntp.isc.org
http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg