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

Joseph Gwinn joegwinn at comcast.net
Thu Mar 18 13:49:56 UTC 2010

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=48295137L4-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.


Joe Gwinn

More information about the questions mailing list