In servalan.mailinglist.macbsd you write:
>That's a mac68k-specific problem.  The mac clock is not keeping up with
>the flow of real time (in Apple's infinite wisdom, they put the clock
>tick on the lowest priority interrupt), so I've disabled the ability to

Yes, and even if you aren't dropping interrupts, the clock still may not be
accurate.  I've had a good bit of experience running xntpd on A/UX boxen (one
of the public stratum-2 servers on MIDNet used to be a Mac) and from what I
can tell, the clocks just aren't very accurate.  Even on an unloaded IIx,
SE/30, or
Quadra 700, I found, the clocks averaged 400ppm slow (that's losing half
a minute every day.)  For a brief period when the s2 server was on a IIsi, 
I discovered the IIsi clock was even worse, ~2000ppm fast (that's gaining
3 minutes every day).  And remember, that's what the clock inaccuracies are
like on an *unloaded* system; a loaded IIx will fall even further behind. 
(On the other hand, this implies that a loaded IIsi will keep good time, as
long as you keep it just loaded enough. :-)

A/UX (like some other Unixen, including SunOS, I believe) manages to paper
over this problem of dropping clock interrupts (and having a fairly lousy
clock in the first place) by having a regularly scheduled kernel task that
adjusts the kernel's idea of time based on what the PRAM clock says.  This
works good as long as you don't have some other source of time (like ntpd)
-- if you do, ntpd and the PRAM play tug-of-war over the system time, and
mass confusion reigns.  SunOS lets you shut off the syncing of kernel time
from the PRAM clock (you'll see mention of the kernel variable 'dosynctodr'
in the ntp docs; that's what controls it.)  A/UX doesn't have such a variable,
and the only way to turn the syncing on/off is to patch the kernel binary
:-(.  If NetBSD/mac were to do such a thing, it should probably be controllable
thru a kernel variable, or even better thru sysctl...

>set the time-of-day clock in the PRAM.  That message is just there to
>let you know that it's not writing to the PRAM.  I'd like to figure out
>a way to let it update the PRAM when it's set from some reliable source,
>but not on shutdown.  I've not looked into that, yet.

As I recall, the way A/UX does it is this (SunOS probably does it this way 
too, but I'm not certain of that):  settimeofday() causes the kernel to set
the PRAM to be the same as whatever it sets the kernel's idea of the time
to be.  adjtime() doesn't set the PRAM, because you don't want to be fiddling
the PRAM clock everytime xntpd does an adjtime() (every 4 seconds, isn't it?)
and the PRAM clock isn't good to better than 1 second anyway. 

>The problem was that for machines that aren't using ntp, the clock
>would fall behind and then get updated on reboot to the MacOS so
>that the MacOS time would be way wrong.

Yeah, updating the PRAM on shutdown is the Wrong Way.  updating on 
settimeofday() seems more reasonable.