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=48295cccnu3e5cmGhOzAS7hA- > >>pVG3A> > >> > >>Once again statestr.c is your friend: > >> > >><http://ntp.bkbits.net:8080/ntp-dev/libntp/statestr.c?PAGE=diffs&REV=4829513 > >>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
