So, I tried bringing up NTP with the kernel PLL support (options NTP)
on my pc164, and was horrified to see a ~560ppm frequency error in the
system's clock.  NTP can only really deal with about a 500ppm error,
so this really blows accurate timekeeping out the window.

It turned out that this was due to an MI software bug.

On alpha, hz=1024; this does not divide evenly into 1000000; as a
result, you lose 576us per second if you just increment the clock by
(1000000/hz) us per hardclock interrupt.

The non-NTP path has a pair of variables (tickfix and tickfixinterval)
which allow this error to be corrected.

It turns out that the NTP PLL support has a nearly-equivalent
variable, fixtick, but (at least on alpha) it was never getting set to
a nonzero value; I just committed a change to -current's kern_clock.c
to set it (to 1000000 - (hz*tick)) if it was zero; currently, only the
pmax port sets it in MD code.

Thanks go to Christoph Badura for pointing me in the right direction
for this fix, and to Ross Harvey for helping me determine that it
wasn't just a hardware problem with my system.

					- Bill