[ntp:questions] Is this a bug? Different outputs from ntpdc -c kerninfo

Dave Hart davehart at gmail.com
Thu Feb 9 12:19:18 UTC 2012


On Wed, Feb 8, 2012 at 19:59, David J Taylor
<david-taylor at blueyonder.co.uk.invalid> wrote:
> Running on my Windows PC (ntpd 4.2.7p241) I get:
>
> C:\>ntpdc -c kerninfo pixie
> pll offset:           0.001216 s
> pll frequency:        27.793 ppm
> maximum error:        0.005504 s
> estimated error:      2e-006 s
> status:               2107
> pll time constant:    4
> precision:            1e-006 s
> frequency tolerance:  496 ppm
> pps frequency:        27.793 ppm
> pps stability:        0.010 ppm
> pps jitter:           0.002575 s
> calibration interval: 256 s
> calibration cycles:   162536
> jitter exceeded:      30763
> stability exceeded:   0
> calibration errors:   11
>
>
> Whereas logged into the FreeBSD 8.0 system (ntpd 4.2.4p5) I see:
>
> pixie-ii# ntpdc -c kerninfo
> pll offset:           -3.27e-07 s
> pll frequency:        27.779 ppm
> maximum error:        0.000508 s
> estimated error:      2e-06 s
> status:               2107  pll ppsfreq ppstime ppssignal nano
> pll time constant:    4
> precision:            1e-09 s
> frequency tolerance:  496 ppm
> pps frequency:        27.779 ppm
> pps stability:        0.010 ppm
> pps jitter:           2.726e-06 s
> calibration interval: 256 s
> calibration cycles:   162535
> jitter exceeded:      30763
> stability exceeded:   0
> calibration errors:   11
> pixie-ii#
>
>
> Not only do the numbers look different, but the 2107 status isn't decoded.
> Your thoughts?

ntpdc uses binary structures on the wire, and assumes implicitly all
systems have identical binary representations.  That works fine for
integers, apparently not so well for floating-point.  Further,
kerninfo in particular is horribly implemented in ntpdc, as the
decoding of the status bits depends on the client's kernel headers
related to NTP kernel extensions being identical between the system
where ntpdc was built and the system where ntpd was built -- meaning
you can get incorrect decoding querying between two systems which have
slightly different numeric values for some of the kernel NTP
bitfields, which should be a local implementation issue and not
presumed identifcal across all systems.  Here, Windows has no kernel
NTP extensions so it can decode none of the bits.  ntpq's kerninfo
repairs all these flaws -- it uses text representation of numbers on
the wire, so for both integer and floating-point types, there can be
no misunderstanding.  Further, ntpq's kerninfo relies on ntpd to
decode the flags bit values into flag names, so again it matters not
if ntpq was built on a system without kernel NTP extensions, or with
slightly different extensions.  In a few cases, the numbers are the
same but simply represented differently, simply because FreeBSD's
*printf() functions make different choices than Microsoft C about when
to use scientific notation given identical format strings and values.

All of these issues are known, and I don't believe any could be fixed
in ntpdc and ntpd without introducing new on-wire mode 7 operations,
which would work only with new ntpd and ntpdc.  All are fixed by new
ntpd and ntpq.

Once I send this mail I plan to paste this text into the recent bug
report filed for this issue, and resolve it indicating there will be
no fixes for these reasons.  I apologize for taking longer than usual
to respond -- real life intrusions combined with the flood of
questions@ list traffic when the newgroup gateway was fixed conspired
to overwhelm me.

Thanks for the report,
Dave Hart


More information about the questions mailing list