In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (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 _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions