On Wed, Feb 8, 2012 at 19:59, David J Taylor <[email protected]> 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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
