Request for data / ntpsnmpd report

Ian Bruene ianbruene at gmail.com
Wed Jan 24 17:28:47 UTC 2018


Accidentally replied to ESR directly instead of the list....

Update on previous status.

On 01/09/2018 11:42 AM, Eric S. Raymond wrote:
> Heads up, Hal!  I'd like your opinopn on these.
>
> Ian Bruene via devel<devel at ntpsec.org>:
>> * Time Resolution (not to be confused with Time /Precision/, which is one of
>> the first entries I implemented)
> [...]
> I think the third way is probably best - returning sys_fuzz.

I believe I have nailed this one down. The mode 6 variable name is "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.

Doing some grepping reveals that "root distance" == "synchronization 
distance" (see /docs/select.txt), and I had already established that 
"root dispersion" was something else. I am currently trying to pin down 
what variable to ask mode 6 for , it looks like it might be 
"root_delay", but I am unsure. (yay for consistent naming!)

It could be root_delay + something_else.

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

Still no clue here. The way the MIB is worded would exclude just 
slurping up the config file and monitoring for changes.

-- 
/"In the end; what separates a Man, from a Slave? Money? Power? No. A 
Man Chooses, a Slave Obeys."/ -- Andrew Ryan

/"Utopia cannot precede the Utopian. It will exist the moment we are fit 
to occupy it."/ -- Sophia Lamb

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20180124/92776b85/attachment.html>


More information about the devel mailing list