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

Dave Hart davehart at gmail.com
Thu Feb 9 12:36:30 UTC 2012

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

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

Dave Hart

More information about the questions mailing list