At 1:57 PM -0700 8/11/98, Capt. Avram Dorfman wrote:
>Is there any better info out there about dealing w/ the clock problem,
>besides what's in the macbsd.com FAQ?

I haven't read the FAQ in a while, but I did look into this problem.

The reason the Mac keeps lousy time is that the hardware interrupt
priorities are set according to some strange philosophy of importance that
does not correspond to good system design.  The user is the most important
thing so the mouse gets highest priority.  OS housekeeping is unrelated to
serving the user so the clock gets the lowest priority.  Therefore if
*anything*at*all* is happening in the kernel due to an interrupt of any
kind the clock interrupt is locked out and you loose time.

I was told by Johnathan Stone (who had something to do with the relevant
code) that the situation might improve if you used the FLL instead of the
PLL or hybred FLL/PLL that is the default.  I don't know how to do this.
There is a flag that the kernel souce checks to determine which mode to
use, but I don't know how to get it set.  Do you do an
options	NTP=<flag>
in the kernel config, or what?

Anyway the bottom line is that you can't run ntp.  All the machinery is
there, but if you turn it on the loop never stabilizes to the point where
it will start adjusting the local clock.  That's the *official* explanation
anyway.  It also never gives you a meaningful error message in the syslog
until several days later, which bugs me a bit.  If you don't specifically
look at the loop parameters or check timestamps you think everything is
working for quite a while before it becomes obvious.

In short I *could* tell you how to set up the /etc/ntp.conf file, but
there's no point.  Just do what everybody else does (including me) and put
ntpdate in a cron job.  There's even a /etc/rc.conf option to do this for
you.

Sorry to bear bad news.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu