[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