Request for data / ntpsnmpd report

[Eric S. Raymond]

Heads up, Hal!  I'd like your opinopn on these.

Ian Bruene via devel <devel at ntpsec.org>: 
> I have nearly finished filling out the MIB tree for SNMP. What gaps are left
> involve data I do not know how to get:
> 
> * Time Resolution (not to be confused with Time /Precision/, which is one of
> the first entries I implemented)

The situation here is somewhat confused.

For reference, here is everything RFC 5907 has to say about this entry:

ntpEntTimeResolution OBJECT-TYPE
    SYNTAX      Unsigned32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The time resolution in integer format, where the resolution
        is represented as divisions of a second, e.g., a value of 1000
        translates to 1.0 ms."
    ::= { ntpEntInfo  5 }


The cheap and cheesy way to fill this in would be to return 10e6 or 10e9
dependoing on whether the system clock call returns at microsecond or
nanosecond precision.

A second way would be to to replicate the get_resolution() measurement
in ntpfrob/precision.c, but be careful about the units returned.

Third way: there's a reference to get_resolution() ntp_systime.c at
line 147 ("After default_get_precision() has set a nonzero sys_fuzz")
that implies two things; (1) get_resolution() used to be called within
ntpd, and (2) its role has been taken over by the system variable
sys_fuzz, which is exposed through Mode 6.  We could return that,
scaling it as the RFC requires.

I think the third way is probably best - returning sys_fuzz.

> * Time Distance

ntpEntTimeDistance OBJECT-TYPE
    SYNTAX      DisplayString
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The distance from this NTP entity to the root time reference
        (stratum 0) source including the unit, e.g., '13.243 ms'."
    ::= { ntpEntInfo  7 }


This could refer to one of three concepts: "root distance", "root
dispersion" "synchronization distance".  I am not entirely sure these
are all different things (!) as the documentation around them is
remarkably obscure - I refactored the code without fully understanding it.

I *think* "synchronization distance" is about the hop to the peer that
shipped the most recent packet accepted, while "root distance" and
"root dispersion" are the same statistic cumulated back to the root.
Hal or Daniel might know more than I do here.

If my belief is correct, you can fill this in with the mode 6
"rootdisp" system variable.  But I'd like a sanity check on this. If
you're feeling brave, grep for these terms in the documentation and
develop your own theory.

> * Validation for the TestSet sequence. According to the RFC this is one of
> the most complicated parts of an agent to get right. Currently it is setup
> to be failsafe, which we can get away with for now because the NTP MIB only
> has two writable entries, and simple ones at that.

I don't understand this at all.  Where is it in the RFC?

> * Check if ntpd configuration changed. The description listed in the RFC is:
> "The notification to be sent when the NTP configuration has changed, e.g.,
> when the system connected to the Internet and was assigned a new IP address
> by the ISPs DHCP server.". But I do not know the full extent of what to
> check, or how to do so.

ntpEntNotifConfigChanged NOTIFICATION-TYPE
    OBJECTS     { ntpEntStatusDateTime, ntpEntNotifMessage }
    STATUS      current
    DESCRIPTION
        "The notification to be sent when the NTP configuration has
         changed, e.g., when the system connected to the Internet and
         was assigned a new IP address by the ISPs DHCP server."
    ::= { ntpEntNotifications 6 }

I have no idea how to check for this either.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.