[ntp:questions] SNMP support

Svein Skogen svein at d80.iso100.no
Fri Dec 14 13:54:22 UTC 2007


(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.

But, given that todays clocks are quite a bit more accurate than they
were when ntp was conceived, a different unit than milliseconds might be
a better solution than using a float, since floating numbers on our
binary computers are inaccurate by design. Couldn't we solve this
floating point problem by making a change in the internals of the code,
to use nanoseconds (thus moving the decimal point quite far, and
delaying our floating point problem to our grandchildren to solve)? SNMP
has no problems in sending LARGE numbers, but it does have in sending
the small fractions (floating point). If we do this by using two
variables, such as Full_Seconds and Nano_Second_Offset, there should be
sufficient precision to outlive our current perspective?

I know that such a change will in parts increase the complexity of the
current codebase, and I know that there are plenty on this list that can
refine this idea (or give a very good explanation why this is stupid :)
), but can we atleast consider it?

Regards,

Svein Skogen.


p.s. My current internet service provider does not have any nntp
service, so replies to me should go through the questions-list or to my
direct mailbox.


-- 
Svein Skogen		| svein at d80.iso100.no
Solberg Østli 9		| PGP Key:	0xE5E76831
2020 Skedsmokorset	| svein at jernhuset.no
Norway			| PGP Key:	0xCE96CE13
------------------------+-----------------------------
msn messenger: 		| Mobile Phone:	+47 907 03 575
svein at jernhuset.no	| RIPE handle:	SS16503-RIPE

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntp.org/pipermail/questions/attachments/20071214/0556eb86/attachment.pgp>


More information about the questions mailing list