[ntp:questions] SNMP support
Joseph Gwinn
joegwinn at comcast.net
Fri Dec 14 18:27:15 UTC 2007
In article <47628B0E.4080308 at d80.iso100.no>,
svein at d80.iso100.no (Svein Skogen) wrote:
> (I took the liberty of removing the lower half of this mail. See
> previous mails in this thread for complete history)
> David L. Mills wrote:
> > Heiko,
> >
> > A couple of comments about this mission. First, last I looked SNMP had
> a
> > really hard time with floating point and the scaling issues are
> > dangerous. Second, as mentioned several times on the NTP hackers wire,
>
> > we would very much like to shoot ntpdc and its fascist (mode 7)
> > protocol. As of now, many configuration issues can be performed using
> > the mode-6 (ntpq) protocol. While many ntpdc related issues can be
> > easily moved to the mode-6 protocol, which is based on UDP, the monlist
>
> > function of ntpdc really needs TCP, as experience with monlist and UDP
>
> > demonstrates. This paritcular combination of UDP and TCP would not be
> > friendly to SNMP.
> >
> > I continue to speculate that an SNMP agent in an expert system would be
>
> > an ideal shotgun marriage between mode-6 and SNMP.
> >
> > Dave
> >
>
> Disclaimer: I know parts of this has already been answered in the
> thread, and I know that a lot of the basis for my comments are made
> solely based on my memory of things, and memory (when you start to get
> my age) isn't a perfect match of things that were, but rather some
> guidlines to how things might have been. Thus I may be totally wrong, or
> answering the wrong question. (Now, I can get to the point. :) )
>
> One of the tricks I used in the old days for handling decimal numbers
> (which is why we need the floating point, isn't it?) was to use two
> variables, or to use a different (moving the decimal point) internal
> value, and dividing by 10^x for display.
>
> I'm guessing that what we need the floating point for, is the precision
> on our peers, and the precision of our drift. These values are (iirc)
> today a float number of milliseconds. And for all simplicity, they
> should remain that way for human presentation, to avoid unnecessary
> confusion.
An alternative that comes to mind is to use the scaled binary
representation of the base two logarithm of the millisecond value in
question. Zero would need to be handled as a special case. If the
value is signed, then a sign field will also be needed.
For example, one could express 274591 milliseconds as 1000*Log2(274591)=
18066.9248, or rounded to the integer 18067.
Joe Gwinn
More information about the questions
mailing list