>   Common sense at least as I understand it, is that if you want small
> delays, you use [the standard PC] timer for them and *no* future
> alteration in clock speed will ever affect it.

This only works for reasonable length times (the 2uS that someone mentioned
is WAY too short.)  It's also not particularly usable in a multitasking
environment.

Our (big) IOS has a nice tree-structured timer mechanism.  You can build
little timer trees that are carefully sorted when you activate a timer, so
that the tree that is its parent only has to look at the "top" to see if any
timer in the tree has expired.  Eventually, the scheduler looks at some
small number of timers and compares them with a clock driven off the NMI.
Cute, and efficient from a scheduler perspective, depending on how often you
start new timers (which may cause a re-sort of that portion of the tree.)
The NMI is some few milliseconds, though.  For accuracy to less than 100ms
or so, you need something else.  For times less than a clock tick, you need
something else whether you need accuracy or not.

BillW