On Tue, 4 Jan 2000, Henry B. Hotz 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?

Yes. No.

> >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.

> 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.

Nothing's different in 1.4. Doesn't "current" use the alternate
priorities on 840av already? I ran a wscons kernel for about a week,
and I'm sorry to say it loses time just as badly as 1.4.x.

Another problem with the 840av is that the processor effectively stops
during disk I/O. In theory, the processor continues to run (but no
memory access) while the PSC is doing dma, but I suspect the
processor's cache isn't large enough to let it do anything useful.

> As a workaround I can't use NTP, but ntpdate in a cron job works just fine.

I use timed, with the 840av slaved to an amd-k6 master running ntpd.
The divergence varies up to 3s, with an average of less than 1s--still
not good enough to do builds over nfs without "make" complaining, but
otherwise a reasonable solution.