[ntp:questions] NTPv4 Peer Event Codes - secret decoder ring sought
Joseph Gwinn
joegwinn at comcast.net
Sat Mar 20 01:24:39 UTC 2010
In article <slrnhq850s.183.unruh at wormhole.physics.ubc.ca>,
unruh <unruh at wormhole.physics.ubc.ca> wrote:
> On 2010-03-19, David Mills <mills at udel.edu> wrote:
> > Joe,
> >
> > That's a typo; event 16 does not exist. Glad you caught that.
>
> Pretty elaborate typo. Did they mean to give it a number other than 16,
> or were 50 letters somehow mistyped?
Ahh, be nice. We all know perfectly well how such things happen.
Joe Gwinn
> > Joseph Gwinn wrote:
> >
> >>Dave,
> >>
> >>In article <4BA2C1FF.3060803 at udel.edu>, David Mills <mills at udel.edu> wrote:
> >>
> >>
> >>
> >>>Joe,
> >>>
> >>>You and Dave are working way too hard. The bits and pieces are
> >>>documented on the ntpq page and on the Event Messages and Status Codes
> >>>page.
> >>>
> >>>
> >>
> >>This would be <http://www.eecis.udel.edu/~mills/ntp/html/decode.html#peer>,
> >>which I didn't know about, but is exactly what I seek. And it wasn't a
> >>secret
> >>after all.
> >>
> >>But I have a question, a homework example, and a suggestion.
> >>
> >>First the question: The Code field of the Peer Status Word is 4 bits wide,
> >>and
> >>yet codes are defined for values from 1 to 10 hex (decimal 16), which
> >>doesn't
> >>quite map. How does the code value fit into the field? Wraparound, so 10
> >>(TAI)
> >>becomes zero?
> >>
> >>
> >>The homework example: The PSW word that started this exercise is "963a".
> >>If I
> >>understand, this word decodes as follows:
> >>
> >>Status field - host_reachable plus persistent_association
> >>
> >>Select field - system_peer (gets the star)
> >>
> >>Count field - 3
> >>
> >>Code field - become system peer (assuming code values are truncated to 4
> >>bits,
> >>so hex 10 becomes 0)
> >>
> >>And 9614 decodes to host_reachable plus persistent_association, system_peer
> >>(gets the star), count=1, and server_reachable.
> >>
> >>
> >>And the suggestion: I was misled by some of the NTPv4 documentation,
> >>specifically the NTPv4 peerstats file documentation in
> >><http://www.eecis.udel.edu/~mills/ntp/html/monopt.html>.
> >>
> >>The note under the table defining peerstats record fields reads "The status
> >>field is encoded in hex format as described in Appendix B of the NTP
> >>specification RFC 1305". This is no longer really true, as you discuss
> >>below.
> >>In particular, codes exceeding 5 are not defined in 1305, and some of the
> >>definitions appear to have changed (or at least have been clarified) so it
> >>would
> >>be helpful to add a pointer to
> >><http://www.eecis.udel.edu/~mills/ntp/html/decode.html#peer> to
> >>monopt.html.
> >>
> >>
> >>
> >>
> >>>RFC-1305 was written in 1992. It's been 18 years since then, so you
> >>>should expect changes from time to time. Changes are not done lightly;
> >>>they reflect updates in the algorithms and interpretation of the
> >>>statistics and state variables. If the interpretation has not changed,
> >>>the name and code have not changed. If it has been changed or has become
> >>>obsolete, the name is not reused.
> >>>
> >>>
> >>
> >>This is good. There is far too much existing base to do it any other way.
> >>
> >>Thanks,
> >>
> >>Joe Gwinn
> >>
> >>
> >>
> >>
> >>>Dave
> >>>
> >>>Joseph Gwinn wrote:
> >>>
> >>>
> >>>
> >>>>In article
> >>>><46f5ae0a-93d6-44ea-812f-e4da2ae2c8a6 at a16g2000pre.googlegroups.com>,
> >>>>Dave Hart <davehart at gmail.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>There were backward-incompatible changes on May 13, 2008 for ntp-dev
> >>>>>4.2.5p114:
> >>>>>
> >>>>><http://ntp.bkbits.net:8080/ntp-dev/?PAGE=cset&REV=48295cccnu3e5cmGhOzAS7
> >>>>>hA-
> >>>>>pVG3A>
> >>>>>
> >>>>>Once again statestr.c is your friend:
> >>>>>
> >>>>><http://ntp.bkbits.net:8080/ntp-dev/libntp/statestr.c?PAGE=diffs&REV=4829
> >>>>>513
> >>>>>7L4-SOuAy6YZauDbZtW6DRg>
> >>>>>
> >>>>>If you want to be able to decode these bits for ntpd versions from
> >>>>>before and after the change correctly, you need to query the version
> >>>>>string of ntpd, sadly, such as with:
> >>>>>
> >>>>>ntpq -c "rv 0 version"
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>So that's how you get the NTP version (rather than the ntpq version)!
> >>>>
> >>>>When our sysadmins first installed NTPv4, they used the version command
> >>>>of
> >>>>ntpq,
> >>>>which said "4". Check!
> >>>>
> >>>>I came by a few days later to look at the purported NTPv4 loopstats and
> >>>>peerstats files, and (ever suspicious) checked to see what version of NTP
> >>>>had in
> >>>>fact generated them. Still NTPv3. The sysadmins had been snookered by
> >>>>ntpq,
> >>>>which failed to make unambiguous whose version it was reporting upon.
> >>>>
> >>>>This had also happened to me back in the days of NTPv3, but I was saved
> >>>>because
> >>>>I knew that "4" could not be the answer. But I never did figure out how
> >>>>to
> >>>>get
> >>>>ntpq to tell me the version of the ntp daemon.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>and then parse for 4.2.5p114 or later. The format for the version
> >>>>>string can include an optional -RC# suffix, and before long, there may
> >>>>>be releases with a -beta# suffix in the -stable branch, such as
> >>>>>4.2.6p2-beta1 as a prelude to 4.2.6p2-RC1.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>Still evolving, rapidly. OK. I will have to find out exactly which
> >>>>version
> >>>>I
> >>>>have. I have no need to decode status from prior versions. I need only
> >>>>to
> >>>>understand the status codes from what I am running, to understand what is
> >>>>and is
> >>>>not working in my system. Fixes have included giving NTP and related
> >>>>traffic
> >>>>its own dedicated LAN and LAN ports on the hosts, to reduce buffeting of
> >>>>NTP
> >>>>packets and/or the daemon by unrelated but heavy packet traffic. The
> >>>>buffeting
> >>>>causes what appear to be large, random, and often asymmetric transport
> >>>>delays.
> >>>>
> >>>>Is there available a written discussion of which changes were made and
> >>>>why?
> >>>>This could be worth reading.
> >>>>
> >>>>More generally, these backward-incompatible changes will cause great
> >>>>confusion
> >>>>and difficulty in transitioning to NTPv4 unless ntpq is kept up to date,
> >>>>and
> >>>>the
> >>>>descriptions of what the various status codes mean are both complete and
> >>>>correct
> >>>>- telegraphic summaries are not usually enough for non-developers to
> >>>>understand.
> >>>>
> >>>>Looking at the code you suggested, I also see that the variable names are
> >>>>the
> >>>>same as in NTPv3 (and the names imply the original NTPv3 meanings), but
> >>>>the
> >>>>new
> >>>>NTPv4 comments on those variables seem to contradict the meanings implied
> >>>>by
> >>>>the
> >>>>names. Not knowing the history makes it difficult to figure out just
> >>>>what
> >>>>is
> >>>>now meant.
> >>>>
> >>>>Thanks,
> >>>>
> >>>>Joe Gwinn
> >>>>
> >>>>_______________________________________________
> >>>>questions mailing list
> >>>>questions at lists.ntp.org
> >>>>http://lists.ntp.org/listinfo/questions
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >>_______________________________________________
> >>questions mailing list
> >>questions at lists.ntp.org
> >>http://lists.ntp.org/listinfo/questions
> >>
> >>
More information about the questions
mailing list