> > This is pretty much the timer code rewrite I occasionally suggest.
> > Since the internal timer has a much higher resoloution than the RTC
> > timers, but the resoloution at which it is used is lower than the RTC
> > timers, I once again suggest moving the main clock off to an RTC to
> > free up the internal time for one-shot use ...like running timer
> > events at a 20k rate for short periods of time as interval timer
> > events.
> 
> I've suggested this too, but I no longer think it's a good idea.  You
> can't read the internal counters of the RTC, so it is inconvenient to
> implement gettimeofday() using it.  You would have to combine the RTC
> tick with the internal counter of the 8254 timer, and the book-
> keeping for this would probably be slower and more complicated than 
> using the 8254 timer for everything.

The gettimeofday() time does not need to be higher resoloution than about
10ms -- this is not the clock that should be used for profiling; I think
the only valid use of what has always been the 10ms LBOLT clock is to cause
a "quantum exceeded" context switch.

For the necessary profiling clocks and the sub-ms time resoloutions on
needed for select() and get/setitimer() (and a real-time scheduling class
f we allow preemption as a result of a timer event), a timer queue is
sufficient.

> I've also suggested reprogramming the 8254 timer to support sub-
> millisecond resolution for timeouts.  This would make it very easy
> to attach new high frequency interrupt handlers to the clock
> interrupt.  However, the extra overhead for the timeout mechanism
> would be unacceptable at an interrupt rate of 20 KHz.

Right -- definitely unacceptable as a continuous interrupt source,
except for burst periods.  That's why a timer queue, with one-shots
and rescheduled events, would be the way to go.  The tricky part
would be shoving the tick resoloution up and down for various
frequencies of events such that the highest resoloution event always
got sufficientl numbers of interrupts for it to keep up.

The easy way to handle this would be a dide-by-two frequency choice so
that each frequency allowed was some 2**n for an integer n.  Then instead
of multiplies and divides, simple shift operations could be used for
frequency adjustments, and a binary hard-coded compare could find the
highest necessary resoloution with and+compare -- log2(32)==5 compares,
or a bit string operation if one is available on the processer.


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.

------------------------------------------------------------------------------