In article <[email protected]>, unruh <[email protected]> wrote:
> On 2010-03-19, David Mills <[email protected]> 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 <[email protected]>, David Mills <[email protected]> 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-e4da2ae2c...@a16g2000pre.googlegroups.com>, > >>>>Dave Hart <[email protected]> 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 > >>>>[email protected] > >>>>http://lists.ntp.org/listinfo/questions > >>>> > >>>> > >>>> > >>>> > >> > >>_______________________________________________ > >>questions mailing list > >>[email protected] > >>http://lists.ntp.org/listinfo/questions > >> > >> _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
