Messages in this thread | | | Date | Tue, 10 Apr 2001 04:43:36 -0700 | From | David Schleef <> | Subject | Re: No 100 HZ timer ! |
| |
On Mon, Apr 09, 2001 at 11:35:44PM +0100, Alan Cox wrote: > > > Its worth doing even on the ancient x86 boards with the PIT. > > > > Note that programming the PIT is sloooooooow and doing it on every timer > > add_timer/del_timer would be a pain. > > You only have to do it occasionally. > > When you add a timer newer than the current one > (arguably newer by at least 1/2*HZ sec) > When you finish running the timers at an interval and the new interval is > significantly larger than the current one. > > Remember each tick we poke the PIT anyway
Reprogramming takes 3-4 times as long. However, I still agree it's a good idea.
RTAI will run the 8254 timer in one-shot mode if you ask it to. However, on machines without a monotonically increasing counter, i.e., the TSC, you have to use 8254 timer 0 as both the timebase and the interval counter -- you end up slowly losing time because of the race condition between reading the timer and writing a new interval. RTAI's solution is to disable kd_mksound and use timer 2 as a poor man's TSC. If either of those is too big of a price, it may suffice to report that the timer granularity on 486's is 10 ms.
It would be nice to see any redesign in this area make it more modular. I have hardware that would make it possible to slave the Linux system clock directly off a high-accuracy timebase, which would be super-useful for some applications. I've been doing some of this already, both as a kernel patch and as part of RTAI; search for 'timekeeper' in the LKML archives if interested.
dave...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |