Dave M,
At 9:48 PM +0000 3/19/10, David Mills wrote:
Joe,
That's a typo; event 16 does not exist. Glad you caught that.
Ahh. So the other codes are as stated, and zero is not used. Glad
to be of help.
Joe
Dave
Joseph Gwinn wrote:
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
[snip]
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
