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

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


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 

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.


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