NTPv4 MIB Initial draft

Dave,

The monitoring system is actually trying to verify
sub-millisecond synchronization and the precision of 10
microsecond with rounding does not give enough room to look
for trends in data. The errors measured are of a second
order so the microsecond precision helps to verify the
accuracy of the measurement with error. As you said both the
ntpq and the ntpd programs would have to change to increase
the precision. That is one of the reason for using ntpdc. I
understand your point about the maintenance of ntpdc, but I
believe I need the precision. So I, don't have a solution.
SNMP might be a solution if it retrieves the data from the
ntpd directly and provides the required precision. I thought
that one of the suggested approaches was that snmp uses
mode-6 queries to obtain the data from the ntpd. My comments
were that this approach would not provide the precision
required. 

As to the usefulness of the filter order. Investigation of
ntp synchronization problems with different versions of the
ntpd software, required looking at the order that the ntpd
was using to determine why clocks were drifting or not
synchronizing fast enough. i.e. Ntpd v3-5.93e on a solaris
platform synchronizes to 0.5mS in less than 1 hour, but
v4.2.01.1161-r takes almost 3 hours. The main reason for
this is because the order of the filter data. This would not
have been verified without the order being provided. I don't
want this discussion to deteriorate into a discussion of the
behavior of ntpd (that can be taken offline if you would
like details). I just wanted to point out the usefulness of
the filter order being provided in the mib.

Ron

-----Original Message-----
From: ntpwg-bounceslists.ntp.isc.org
[mailto:ntpwg-bounceslists.ntp.isc.org]On Behalf Of David L.
Mills
Sent: Monday, January 23, 2006 14:21
Cc: ntpwglists.ntp.isc.org
Subject: Re: [ntpwg] NTPv4 MIB Initial draft

Ron,

With due respect, I don't buy this. All the ntpq data except
the filter 
data are maintained to external microsecond precision. The
filter data 
are maintained to ten microsecond precision only for
convenient display. 
It's easy to increase the precision to the microsecond, but
all ntpq 
programs would have to change in order to reformat the raw
data for 
consistent display.

Since most of the ntpq performance data are floating doubles
converted 
to milliseconds and fraction, the question of precision is
not relevant. 
Much experience with precision sources and crafted kernels
suggests that 
sub-microsecond external display precision is not useful in
practice.

The filter order in the ntpq display is not relevant, as the
order of 
the display is the order of the filter. I don't know if
ntpdc displays 
in error or not. The actual internal order is not useful,
unless you are 
looking for program bugs. In that case the debug trace is
more appropriate.

Dave

Pashby, Ronald W CTR NSWCDD-B35 wrote:

> I have created a extensive NTP monitoring system to
determine if all 
> hosts
> maintain a given sub-second time offset between each
other. In order 
> to do
> this I was using ntpdc to retrieve certain values. I
investigated 
> using ntpq instead, but some of the values in the
mode-6 protocol do 
> not provide sufficient precision, specifically in the
filtoffset. The 
> filter order was missing from the mode-6 protocol. If I
were to do 
> this using SNMP and mode-6 protocol was used to obtain
the raw data it 
> would not be sufficient.
>
> This could be fixed by increasing the precision of the
mode-6 data and 
> adding the filter order data.
>
> Also, I noted an occasional inconsistancy of the filter
delay values 
> reported from ntpdc and ntpq. Is this ntpdc rendering
the value wrong 
> or ntpd (via mode-6 protocol)?
>
> -----Original Message-----
> From: ntpwg-bounceslists.ntp.isc.org
> [mailto:ntpwg-bounceslists.ntp.isc.org]On Behalf
Of David L. Mills
> Sent: Monday, January 09, 2006 13:42
> Cc: ntpwglists.ntp.isc.org
> Subject: Re: [ntpwg] NTPv4 MIB Initial draft
>
>
> Heiko,
>
> It is very dangerous to use the mode-7 protocol,
especially as it uses
> field formatted binary packets and is full of tiny
little errors and
> misrepresents some state variables. You don't need ntpq
to use the
> mode-6 protocol. Start ntpq, type raw and see what you
get, which should
> be readily parseable in perl or something like that.
Lift the ASN.1
> library from OpenSSL and the job is virtually done.
>
> As for the data types, the data available is one or
more of the state
> varialbles I so carefully built into the skeleton
program and are
> qccurately typed in that program. I would assume the
MIB use the same
> data types. It's really not a good idea to convert
floating doubles to
> any other representation; the daemon has a very wide
range of data and
> an attempt to can a value in any particular scaled
integer will very
> likely result in loss of fidelity.
>
> For consistency and compact representation, floating
double time offset
> and jiter are displayed in milliseconds with six
fraction digits.
> frequency offset, dispersion and wander are displayed
in PPM with three
> fraction digits. With appropriate macros the format the
display, you
> shouldn't need a binary display type; strings would do.
That should
> vastly simplify the MIB and allow easy conversion to
other types, if
> necessary. This is the same principle used in the
production of
> monitoring data and data transmitted by the mode-6
monitor utility.
>
> Here is a specific suggestion and would make a
candidate MIB a snap to
> produce. Take the state variables in the skeleton, sort
them by prefix
> type as mentioned in the comments. With a text editor
change the
> skeleton names to other names of your fancy. Write a
Q&D C program to
> parse the names and data types and construct an
appropriate MIB entry.
> For MIB comments use the strings in the comments field
of the state
> variable. Presto, most of the dirty work is done. This
is why I did the
> skeleton in the first place.
>
> Once having done this adventure, a rather large number
of MIB variables
> will result and you might want to sift the more exotic
from the mix.
> Now, start from the other end. What do you want the
administrator to
> learn from a query? Now make some rules that say, for
example, "how many
> servers are in use and what is their quality?"
From the available MIB
> entries, scarf up what strings you need and produce
query responses
> similar to the pe and rv commands of ntpq. There are
twenty years of
> experience with those displays; I would think the NTP
administrator
> would be happy to see the same thing with SNTP.
>
> These days there are an astonishing number of NTP
implementations with
> embedded Linux, even in my printers, CDMA reference
clocks and UPSes(!),
> so it's getting harder and harder to find something
running NTP without
> an FPU. Some of our GPS boxes already support a
proprietary MIB, but
> I've never used it, preferring the embedded mode-6
protocol instead. If
> the embedded box has a proprietary MIB, should we be
concerned about a
> lack of FPU?
>
> Dave
>
> Heiko Gerstung wrote:
>
>> Dave,
>>
>> thank you very much for your detailed comments on
the MIB. As this is
>> a first draft, I am really open to discuss any
fundamental principles
>> of it now (if not now, it might be too late
later...).
>>
>> David L. Mills wrote:
>>
>>> Danny passed me a copy of your attachment. I
don't know exactly what
>>> rule the campus/department used to defang the
attachment, but it
>>> could be it considered any file extension it
didn't know about (.mib)
>>> evil.
>>
>> They should upgrade their filtering software, MIB
is plain ascii 
>>
>>> I started to comment and annotate the data, but
after a couple of
>>> hours I reallized something wasn't right. Your
MIB is generally in
>>> two parts, a numeric datum in some format
coupled with a descriptive
>>> name as a string. Sometimes the descriptive
name has some units, like
>>> 10 ms, but the datum has another, like integer.
I noticed an aversion
>>> to floating point. Lots of state variables in
ntpd are in floating
>>> double. An attempt to force them to integer in
some scale or other is
>>> misleading and very likely vulnerable to
headroom clipping or
>>> roundoff error.
>>
>> Well, my basic idea was that a number of
devices/monitor software
>> developers would be grateful being able to just
grab a string and show
>> it to the user or write it in a logfile, while
numeric values are
>> important to be able to check that something is in
a valid range or it
>> is time to throw some administrator out of his bed.
That is the reason
>> I wanted to provide most things in string as well
as numeric format.
>>
>> I understand that a wide range of data in ntp is
using floating point,
>> but to me it does not make a big difference to get
a value like 12543
>> ms or 12.543 seconds or whatever. As long as the
basic unit is fine,
>> it is OK. But of course it is no problem to use fp
variables instead
>> of integers (I guess my FP aversion is a result of
dealing with a
>> number of devices without FPU and even without FPU
emulation, but I
>> agree that these embedded devices will not play a
role in the ntp
>> world AFAICS).
>>
>>> I intened the flow charts and skeleton a basis
for things like the
>>> MIB. I classified the variables and constants
in various ways, like
>>> peer/poll processes, which are instantiated for
each association, and
>>> others, which have only one instantiation, like
the system process.
>>> The variables and constants for each class
represent the real data
>>> considered for the MIB. So, start out with them
all and whittle the
>>> less revealing as experience continues. IN any
case, if the MIB is to
>>> capture some subset of these data, it should
reflect the data type
>>> specific to each one.
>>
>>
>> I have the main application in mind, the MIB is
intended mainly to
>> allow people to monitor and manage their NTP
servers. Only a handful
>> of data fields are needed for most monitoring
requirements and I do
>> not see that there is a real need for a MIB
representing the whole
>> ntp data and statistics model, but: There is a good
chance that I am
>> completely wrong on this. To find out what people
want to do with the
>> MIB is one reason why I asked them to give me
feedback and I really
>> appreciate that you and others do that.
>>
>> Regarding the data type: I will check and change
the data type for
>> every object I can find into FP instead of integer,
if applicable. The
>> "data type should reflect the one of the data
itself" sounds
>> reasonable (if not obvious...) 
>>
>>> I have another more basic problem. The
performance model assumed in
>>> ntpd is based on a number of state variables
like offset, delay,
>>> dispersion and jitter, among others. There are
various statistics
>>> based on these values that represent the
performance model. The
>>> detailed statistics are given in the
architecture briefing on the NTP
>>> project page. The problem of any MIB is either
to play out all the
>>> data values and statistics and have the SNMP
program leave to the
>>> user how to interpret them, or to cook the
values first by ntpd or
>>> whatever remote agent provides the data.
>>
>> As I mentioned above, the latter would make more
sense to me. The
>> "SNMP program" could be either an agent
or a management system. The
>> agent would be the one collecting the data and has
the duty to provide
>> it in a way that the management system easily sees
if things go wrong.
>>
>>> A few years ago Paul Amer of our CIS department
and his student
>>> implemented a remote agent that maintained a
MIB that could be
>>> compiled from a database. When the agent
received a query, it
>>> translated that query into something the NTP
control/monitoring
>>> protocol could understanc, retrieved the data,
updated the MIB and
>>> returned somenthing in MIB format. In
retrospect, this was a very
>>> good idea. It was flexible, required no ntpd
changes and could
>>> determine whether or not ntpd was running.
>>
>>
>> For another project I packed parts of ntpq and
ntpdc into a library
>> and added some API wrapper functions. This way any
application using
>> this library is able to get what it needs to know
about any remote or
>> local ntpd by simply sending mode 6 / mode 7
requests. One of the
>> applications using this is our Time Server Monitor
for Windows
>> (http://www.meinberg.de/english/sw/time-server-monitor.h
tm), so this
>> library seems to do the things Paul's software did.
The Time Server
>> Monitor is free and if you find a Windows machine,
you can download it
>> and let us know if you like it or not.
>>
>>> This brings up an interesting consequences. It
doesn't matter where
>>> the SNMP agent is, since all communication with
the real values is
>>> handled over the net. Best of all, the strategy
for converting raw
>>> data provided by ntpd to different performance
metrics is
>>> programmable. Heck, consider it an expert
system and write it in
>>> Smalltalk. The mission can be sexy and even
heat up the AI guys.
>>
>>
>> Whether the agent part should be integrated into
ntpd or not is
>> another question, but this is not MIB-related and
should be discussed
>> for each implemenation. The complexity of the
current reference
>> implementation seems to have reached a level where
integrating an
>> internal agent might be problematic, so I
personally would favour an
>> "external" approach, too.
>>
>>> I'm not kidding on the Smalltalk issue; I know
of at least two
>>> previous attempts to monitor networks with
expert systems, a BBN
>>> project when the Initernet was young, and an
AT&T project (the
>>> Springsteen project) which looked for red
lights on the national
>>> traffic boards.
>>
>>
>> I think that a lot of effort has gone into the
various management
>> systems available today. Almost all of them use
SNMP for retrieving
>> data from some equipment and have a more or less
sophisticated way of
>> defining rules for turning on red, yellow or green
lights. The nice
>> thing about SNMP is that you can choose to use it
with your own
>> application (e.g. a Smalltalk based expert system)
or any type of
>> SNMP-capable management software, like OpenView or
Tivoli or whatever.
>>
>>
>> Kind regards,
>> Heiko
>>
>>
>>
>>> Dave
>>>
>>> Heiko Gerstung wrote:
>>>
>>>> Hi, Folks:
>>>>
>>>> Please find attached a first draft for the
NTPv4 MIB file.
>>>>
>>>> Let me know what you think and no mercy,
please  I will
need as
>>>> much input/feedback as possible before
putting this into Internet
>>>> draft format for submission...
>>>>
>>>> Kind regards,
>>>> Heiko
>>>>
>>>>
>>>>
>>>>
>>>>
------------------------------------------------------------
------------ 
>>>>
>>>>
>>>>
>>>>
_______________________________________________
>>>> ntpwg mailing list
>>>> ntpwglists.ntp.isc.org
>>>> http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> ntpwg mailing list
>>> ntpwglists.ntp.isc.org
>>> http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg
>>>
>>
>
> _______________________________________________
> ntpwg mailing list
> ntpwglists.ntp.isc.org
> http
s://lists.ntp.isc.org/mailman/listinfo/ntpwg

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

NTPv4 MIB Initial draft

Thread: NTPv4 MIB Initial draft