[ntp:questions] NTPv4 Peer Event Codes - secret decoder ring sought

Joseph Gwinn joegwinn at comcast.net
Fri Mar 19 20:47:58 UTC 2010


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=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
> >questions at lists.ntp.org
> >http://lists.ntp.org/listinfo/questions
> >  
> >




More information about the questions mailing list