hotz@jpl.nasa.gov wrote:

>At 1:48 PM -0800 1/4/00, Paul Sander wrote:
>>donlee_68k@icompute.com wrote:
>>>	2. Why does the clock behave so badly?  If this is a known
>>>	problem in 1.4.1, will it be fixed in the (soon to be releaed??)
>>>	1.4.2?
>>
>>There's some mention in the install notes that the interrupt structure
>>of the Mac somehow interferes with the time-of-day clock, and that running
>>I/O-bound processes will cause the clock to lose several minutes each
>>hour.
>>
>>Apparently there's something inherent in the way that NetBSD interacts with
>>the Mac hardware to cause this, but it's probably fixable; Apple A/UX did
>>not exhibit this problem.  As for how easy such a fix will be can only be
>>ascertained by the NetBSD kernel architects, though.

>A/UX "fixed" it by having an alternate interrupt structure built into
>certain models.  If you ran A/UX on a machine that didn't have the
>modification then A/UX would have the same problem, guaranteed.  Someone
>was looking into using the alternate interrupt priorities, but the problem
>is that it changes an awful lot of low level stuff to use it.

>MacBSD runs on machines, like the 840av, that A/UX was never ported to, so
>we *have* to support the MacOS interrupt priorities.  That said I've heard
>that Scott Reynolds has been gradually moving things around to deal with
>the problem, and that the problem is much less in 1.4 than in earlier
>versions.

FYI, the IIci has the same problem with the time-of-day clock, and it
ran A/UX.

Also, on 1.4 and 1.4.2, I'm losing several minutes a day just from the
nightly crontab.  It's a couple of hours a week when I run backups, so
the slippage is pretty bad.

Your advice about using ntpdate well-taken, even though I've deleted
that from my quote above.  I'll adopt that as time permits and I'm able
to find a stratum 2 (or better) server willing to feed me.

Thanks!