[ntp:questions] Checking NTP status quickly

Dave Hart davehart at gmail.com
Sat Apr 30 15:11:46 UTC 2011


On Sat, Apr 30, 2011 at 01:18 UTC, David J Taylor wrote:
> I have an application where it would be desirable to check that NTP is
> installed and running, and that the offset reported by NTP is within, say,
> one second.  So we don't need millisecond precision, just to have a good
> idea that the PC's clock is correct within a second or so.  I'm thinking
> that a mode-6 packet might do the job, but I have no experience with control
> packets.  Is this the right way to go about things?

Yes, you're on the right track.  Building on POSIXy systems, NTP has a
convenience library libntpq.a used by ntpsnmpd to issue mode 6 queries
to localhost.  Unfortunately, libntpq has not been ported to Windows,
and moreover is built via a bit of a gross hack:  ntpq C sources are
#included into libntpq sources, using #ifdefs to handle the difference
between being a standalone utility and a mode 6 query library.  Fixing
that has been on my list for a long time, but hasn't reached the top.
I'd also like to make libntpq a first-class library, versioned and
installed, that third-party packages could opt to use.  That requires
a bit of review of the interface, as changes after that point would
need to consider library backwards compatibility.

Knowing you're likely targetting only Windows systems, one approach
you could take is getting libntpq.lib building on Windows.  It likely
isn't a big job, as ntpq is already portable to Windows.
Alternatively, you can clone/rewrite just the minimum pieces needed to
accomplish the equivalent of:

ntpq -c raw -c "rv 0 leap offset rootdisp" -c "rv 0 sys_jitter clk_wander"

ntpq's readvar (rv) is limited to three specified variables, though
the on-wire mode 6 protocol allows for more.  Another approach would
be the equivalent of:

ntpq -c raw -c rv

which will fetch the default set of system variables, which in recent
versions include all the variables named above.  Given enough -d
options on the command line, ntpq will dump the raw query and response
packets onscreen.

If you want to support versions older than 4.2.6, be aware some ntpq
variables have been renamed or replaced.  IIRC 4.2.4 calls
"sys_jitter" simply "jitter", but the two are interchangeable so
that's relatively easy to work around.  Trickier is the removal of
4.2.4's "stability".  I believe "clk_wander" comes closest to
providing similar information in newer versions, but the two are not
equivalent (low values of clk_wander are desirable, presumably higher
values of stability are desirable).

At a minimum to accomplish your stated goal your code should ensure
leap != 11 (that's normally displayed by ntpq in octal, so in
raw/on-wire form you want leap 0, 1, or 2, but not 3, which means
unsynchronized), in addition to your offset threshold.  An offset of 0
with leap=11 (3) does not suggest the clock is within one second of
UTC.

It's possible for offset to be instantaneously showing more than 1000
(msec) while the clock is in fact closer than that, due to a
heavily-loaded system or congested network path.

I'd suggest surveying your machines, watching the other variables I
mentioned during ntpd startup and including some sanity-check
thresholds for those as well.  Off the top of my head, for example
sys_jitter < 10000 (10 seconds), clk_wander < 10 (PPM), rootdisp < 500
(msec).

Cheers,
Dave Hart



More information about the questions mailing list