>On Wed, 11 Jul 2001, John wrote:
>
>> Hello,
>> 
>> > I understand the problems old macs have with losing time as described in
>> > the FAQ, I just didn't think it would be this bad. I have a quadra 840av.
>> > I set up a cron to run hourly with ntpdate:
>> >      0 * * * * /usr/sbin/ntpdate -s tick.usno.navy.mil tock.usno.navy.mil
>> 
>>[snip]
>> 
>> I've heard that some systems won't run ntpd if the time is off too much  -
>> that ntpd gets confused or something. Anyone else care to speak of
>> experiences of running ntpd on machines with really screwed clocks?
>> 
>> John Klos
>> 

I ran ntpd on my 68K macs w/ NetBSD for quite a while until I
took them out of production.  I spent some time trying to track down
why the clocks drift so much.

There is a long thread on this subject in this list around January 2000.
Look fr the subject "Re: NetBSD 1.4.1 - Clock stops when doing I/O".

It boils down to some sub-marvelous interrupt handling in the 68K macs.
Clock interrupts can get lost if the kernel is off doing other things that
are higher priority.  It turns out that SCSI I/O is one of these
important things, and that SCSI I/O will leave interrupts disabled for
relatively long periods of time, so when doing heavy I/O, the clock
"slows down".  What I found was that if I pounded
heavily on a SCSI disk, I could get the clock to almost stop for as long
as I wanted.  (Cool. ;-> )

The problem seemed worse on the Q800 series machines than on the IIci/cx
machines, as far as I could tell.

I ran ntpd on the 68K machines, and for the most part, it compensated
pretty well.  ntpd would fail from time to time, though and I had to
check it periodically to make sure the daemon was still running.
I think it would fail when the clock drifted
so badly that it thought something was horribly wrong, and quit.

-dgl-