fixing ntpq billboard's broken "t" column (bug 1338)

[Dave Hart]

Currently the "t" (association type) column in ntpq is terribly
broken, making assumptions that are wrong as often as not in trying to
determine the "t" column value solely based on the IP address. Steve
noticed this and filed http://bugs.ntp.org/1338

I have a proposed fix that reworks the "t" column determination to be
driven by the association's hmode with secondary consideration to IP
address characteristics, such as to distinguish a broadcast server
association from a multicast server association. The output looks
like this (abbreviated):

hart@psp-fb1> ntp-dev-1338/A.*6.3/ntpq/ntpq -p psp-deb1
remote refid st t when poll reach delay
offset jitter
========================================================
ff05::101 .ACST. 16 A - 64 0 0.000
0.000 0.002
192.168.4.255 .BCST. 16 B - 64 0 0.000
0.000 0.002
+psp-os1.ntp.org 192.168.4.22 3 s 53 64 376 0.098
0.043 0.063
+psp-fb1.ntp.org 204.152.187.43 2 u 27 64 377 0.260
0.011 0.030
*psp-fb2-nfs.ntp 204.152.187.43 2 b 17 64 375 0.202
-0.019 0.023

The 4.2.6/4.2.7 ntpq displays "u" in the t column for every one of
those lines, so this is clearly an improvement, but it's also a bit of
an incompatible change. I believe it's bringing the "type" column in
line with common-sense expectations, but there has been concern
expressed about breaking scripts.

If you are using ntpq from a script, please don't scrape the billboard
for information. It's designed for human consumption, and ntpq
provides all the same information and more via rv/readvar in a script
friendly variable=value format.

If you want to give the new behavior a spin, there's a tarball of
4.2.7 + my proposed 1338 fix at:

http://davehart.net/ntp/ntpq/ntp-4.2.7-1338.tar.gz

You can also choose a patch to ntpq/ntpq-subs.c (against 4.2.7 but it
should apply cleanly to at least recent 4.2.5):

http://davehart.net/ntp/ntpq/ntp-dev-1338.pupatch.txt

Cheers,
Dave Hart

[David J Taylor]

"Dave Hart" <> wrote in message
news:d0a8b639-0e8c-435b...@13g2000prl.googlegroups.com...
[]

> If you are using ntpq from a script, please don't scrape the billboard
> for information. It's designed for human consumption, and ntpq
> provides all the same information and more via rv/readvar in a script
> friendly variable=value format.

[]
> Cheers,
> Dave Hart

Thanks for that. I'm afraid that a lot of my Perl scripts for performance
monitoring /do/ scrap the output from various ntpq commands, so changing
those would break my scripts. However, having said that, as long as the
format of the field remains unchanged - i.e. a single character - I don't
think it will affect the particular scripts I use.

Cheers,
David