Erik E. Fair (Time Keeper) wrote:

> The way to fix it is two fold:
> 
> 1. Eliminate as much of the p = spl7(); /* critical code */; splx(p); out
> of the kernel as possible; write device drivers to defer serious processing
> until after the device interrupt is dismissed.
> 
> 2. Run the Network Time Protocol (NTP) daemon on your system. This will
> keep your clock in trim. It assumes a constant connection to the Internet,
> alas.

A third option:
After X (X being some nice value) clock ticks, poll the time from the
PRAM chip, which tends to be fairly accurate (seconds/month loss or gain
instead of seconds/hour using the interrupt method), and update the
system's time value from the PRAM value. Since the system clock
should only fall behind, not ahead of, the PRAM time, you shouldn't 
have to worry about the system clock occasionally going _backwards_,
only forward.

Potiential side affect: if you are timing something, the results may be
slightly skewed since every X ticks the clock may "jump" ahead several 
seconds. This is not perfect, but may be prefered in most cases since 
with the current interrupt method things are inaccurate anyway.

If the X value was set so that it polled the PRAM approximately every
60 seconds, I don't think you'd ever jump more than 1 or 2 seconds, 
and I don't think doing it this frequently would hurt system 
performance at all.

	--John