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

David J Taylor david-taylor at blueyonder.co.uk.invalid
Thu Feb 9 14:09:57 UTC 2012


"Dave Hart" <davehart at gmail.com> wrote in message 
news:CAMbSiYDTTPDsE_jc+5wROq01sydsGOwjfJAhJ7dh_ggYdESa6Q at mail.gmail.com...
> On Thu, Feb 9, 2012 at 12:19, Dave Hart <davehart at gmail.com> wrote:
>> 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.
>
> This is mistaken on my part -- all the data involved is in fact
> integer on the wire, because the kernel NTP extensions do not using
> floating point.  The on-wire structure is:
>
>
> /*
> * Structure used for returning kernel pll/PPS information
> */
> struct info_kernel {
> int32 offset;
> int32 freq;
> int32 maxerror;
> int32 esterror;
> u_short status;
> u_short shift;
> int32 constant;
> int32 precision;
> int32 tolerance;
>
> /*
> * Variables used only if PPS signal discipline is implemented
> */
> int32 ppsfreq;
> int32 jitter;
> int32 stabil;
> int32 jitcnt;
> int32 calcnt;
> int32 errcnt;
> int32 stbcnt;
> };
>
> Values which are conceptually not integers are scaled by 1e-6 or 1e-9
> for display in ntpdc.  The default is 1e-6.  If the system where ntpdc
> is compiled has NTP nanosecond-denominated kernel extensions (aka
> nanokernel, that is, if STA_NANO is defined) and the status value has
> STA_NANO set, then the scale is 1e-9.  Result: mis-scaled numbers when
> querying a nanokernel-enabled system from a non-nanokernel-compiled
> ntpdc (including microkernel like Solaris, and "nonokerne" l like
> Windows).
>
> Still the big picture is the same.  ntpdc kerninfo is particularly
> fragile and should only be used between very similar systems.  ntpq
> kerninfo is robust.  There is no reasonable way to fix this without
> seriously overhauling ntpdc and ntpd, meaning the fix would only work
> with new ntpdc against new ntpd, and given that ntpq gets it right, it
> doesn't make sense to re-engineer the depracated ntpdc/ntpd mode 7
> code.
>
> Cheers,
> Dave Hart

Thanks for that, Dave, and I appreciate the time taken to answer.  When 
you write:  "All are fixed by new ntpd and ntpq.", what minimum release of 
ntp counts as "new"?  I hope that my ntpq 4.2.7p241 is "new", but what is 
the minimum version of ntpd it will converse correctly with?

Thanks,
David 



More information about the questions mailing list