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

Joseph Gwinn joegwinn at comcast.net
Sat Mar 20 01:24:39 UTC 2010


In article <slrnhq850s.183.unruh at wormhole.physics.ubc.ca>,
 unruh <unruh at wormhole.physics.ubc.ca> wrote:

> On 2010-03-19, David Mills <mills at udel.edu> 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 <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=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
> >>>>questions at lists.ntp.org
> >>>>http://lists.ntp.org/listinfo/questions
> >>>> 
> >>>>
> >>>>      
> >>>>
> >>
> >>_______________________________________________
> >>questions mailing list
> >>questions at lists.ntp.org
> >>http://lists.ntp.org/listinfo/questions
> >>  
> >>




More information about the questions mailing list