--- Forwarded mail from toddpw@best.com

>> mac68k skips Step 3, because the Unix clock is inaccurate, usually loses
>> time rapidly on that architecture.  It ``does not trust itself'' to know
>> what time it is better than the battery clock already does.  Thus, NetBSD
>> will never update the battery clock on a mac68k.

>I just have to ask...

>Why hasn't someone hacked up something that reads the battery clock every
>hour and syncs the Unix clock to it?

>Or does everyone use xntp instead?

The literature explicitly discourages using NTP, unless ntpdate is
used to periodically update the clock.  (I think it was in the mac68k
README file.)

I was just wondering (in a vacuum, because I haven't read the code or
understand the design of the kernel in any detail):  Isn't there some way
to give the clock a very high priority interrupt that does nothing but
increment a counter, and periodically read that counter and update the
clock accordingly?  One would think the overhead of such a thing would
be a handful of microseconds even on the slowest machines (might not even
need a context switch) and the hard part can be deferred until other I/O
is complete.  I'm sure there must be a fast, lock-free algorithm that can
keep the clock accurate with such a mechanism.