William F. Hostman writes:
>>From:     sfkaplan@CS.UTEXAS.EDU
>>Whenever I boot NetBSD, the time is correct.  The longer I leave the
>>machine up, the further the system clock drifts away from real time,
>>always in the direction of losing time.  Within a mere day, it will
>>have lost an hour.  But if I restart the machine, the clock is right
>>back on track according to both the Mac side and NetBSD side when I
>>first start up.

Yeah.  The battery-backed-up clock that keeps time when the machine is off
is considerably more accurate than the one that supplies clock interrupts.
Every time you reboot, the kernel clock gets re-initialized from the
battery-backed-up clock, so you get correct time. 

>several mac models have _KNOWN_ (to Apple) clock errors, and the system
>enabler (under 7.x) or a patch to the system file cure this. (see also
>_Upgrading and Repairing Macs_, 1995, I don't remember the publisher). As
>for how to fix under BSD, I don't know.

Yeah.  In addition to the problems that Allan Briggs mentioned about how
common losing clock interrupts is (it happens on A/UX too, under any sort of
decent load), the fact is that the Mac models I've seen have clocks that are
just plain at the wrong damned frequency.  As I recall from the experience
I had back when the MIDNet stratum-2 NTP server at .ecn.uoknor.edu
was a Mac of various flavours, SE/30s, IIx, and Quadra 700s tend to run
consistently circa 400 parts-per-million slow.  The IIsi we had in there
for a while ran ~2000 ppm fast.  (Then came the next rev of A/UX, which spent
so much time in the kernel with interrupts off that we had to move NTP service
off the Mac entirely.  Sigh.) 

So what can you do?  There are several options:
	1) What A/UX (and SunOS, since the Sun-4s (not sure about other Sun
models) had similar problems w. losing clock interrupts) did: Have a regularly
scheduled kernel task that updates the kernel clock from the battery-backed-up
one.  This does fairly good at papering over the problems, as long as you
aren't looking closely at the clock after, e.g., a floppy format. :-).  If
NetBSD/mac is to implement such a solution, there should be a kernel variable
(or, better still, a sysctl option) to turn it off, since having such a task
going on seriously confuses things when you're running some other time-update
system ala NTP.

	2) Do like Allan Briggs apparently does and run ntpdate every 15 min
or so to update your clock from a known good network time server.  

	3) Use the 'tickadj' program from the NTP distribution to twiddle the
'tick' variable in the kernel (the amount that's added to the time every time
a clock interrupt hits) so as to more closely match what the true clock rate
is (i.e, if the clock is running too fast, lower tick, if the clock is 
slow, raise tick).  You'll need to do this anyway if you're going to use the
solution I prefer, 

	4) Run xntpd on your machine.  This will continuously update the time
on your system by contacting a time server on the network, and even when the
network time server is unreachable, xntpd will use its best estimate of the
frequency error in your clock to continuously adjust the time to be as close
as possible to real time.  I like this solution.  The reason you still have to
do the 'tick' fiddling is because xntpd's phase-locked-loop code was designed
to only handle frequency offsets of +/- 100ppm, and as I've said, most of the
Apple clocks seem to have frequency offsets much worse than that.