--- Forwarded mail from hotz@jpl.nasa.gov

>At 11:00 PM -0800 2/1/00, Paul Sander wrote:
>>I was just wondering (in a vacuum, because I haven't read the code or
>>understand the design of the kernel in any detail):  Isn't there some way
>>to give the clock a very high priority interrupt that does nothing but
>>increment a counter, and periodically read that counter and update the
>>clock accordingly?  One would think the overhead of such a thing would

>Yes, there's the rub.  That's basically how NetBSD is *supposed* to work.

>The problem is a basic philosophical decision made when the first Mac's
>were designed:  The most important task of the machine was the user
>interface, therefore the mouse is highest priority, etc, etc.  The timer
>interrupt is lowest priority and you can't change it.

>Except that some models like the C/Q650 have an alternate priority order
>which was put in to improve A/UX support.  Some work has been done to
>enable it in NetBSD, but I haven't heard it's there yet.

How interesting.  I've been using A/UX for years on a IIci, IIfx, and
and Q700.  They don't seem to have problems with their time-of-day clocks;
at least, xclock has always displayed the correct time for me, drifting
a couple of minutes (less than 5) semi-annually.  This seemed to be true
regardless of how hard I pushed the machines I/O-wise, and even on the
IIci with and without its cache card.  Is it possible that something's
been missed?

>BTW, the problem with reading/sync'ing to the hardware clock is that you
>can only read it to the nearest second, or so I've heard.  Pretty poor
>resolution for ntp.

Certainly, if you try to use it at a very low stratum number.