hi,

Yesterday I committed NTP kernel precision timekeeping.  Those changes
should have showed up in today's sups.  Thanks to Christoph Badura
(bad@ora.de) and Jason Thorpe for looking at this code. Any complaints
or bugfixes should be sent to me :).

This change should have no effect unless "options  NTP" is added
to a kernel config file.  If this option is added, then HZ
must also be defined in the kernel configuration file; furthermore,
it must be defined to be a power of 2 between 64 and 1024, inclusive.
Values for HZ of 60 and 100 are also supported.

The reason for this is that NTP's extended-precision timekeeping
uses a shift count.  This shift count is used several times in each
hard-clock interrupt. The alternative  to forcing HZ to be a power
of 2 and using a fixed shift count is an extra divide in _every_ call
to hardclock().   This, rightly or wrongly, is seen as "too expensive".

(the special values of  100 and 60 are just slightly slower than 128,
 and  64, and are handled by a run-time kludge.)

If kernels without "options NTP" behave differently or don't build due
to NTP support, please send a PR. The same applies if kernels
configured with NTP don't behave as expected.  (I'm not sure how to
get a PR to me; using Cc: jonathan@netbsd.org is probably best.)


Adding this kernel support for NTP precision timekeeping means that
xntpd (either xntp 3.4y or xntp3.5a) no longer runs "out of the box"
on NetBSD.   There is at least one one-line fixes that need to be
made.   NTP provides a prototyped declaration of syscall() which is
not correct for NetBSD; the simplest solution is to remove NTP's
declaration (e.g., from xntpd/ntp_request.c) and to do
	#include <unistd.h>
instead.  Also, xntp3.5a seems to define HAVE_TERMIOS twice on
NetBSD;  editing the definition  out of the Makefile is perhaps
simplest.

It's worked well for me with xntp3.4y and xntp3.5a. 

enjoy,

--Jonathan