On Wed, 17 Apr 2002 13:01:00 +0200 (CEST) Tim Goetze <[EMAIL PROTECTED]> wrote:
> Juan Linietsky wrote: > > >RTC is cool, but has the problem that only one program can use it > >at the same time. Do you know if there is any patch aviable to > >make RTC shareable? I know RTC works by using int 8 in x86 > >and that high timings in a very old machine can hog the cpu due > >to the high amount of irq calls. But in the case of nowadays > >computers, i dont see why it should be a problem to have rtc enabled > >by default to the max speed and give each client frequencies based on > >divisors of it. > > try 8192 Hz once and look at the system load, you'll find a good > reason not to do this even on recent systems. Well, besides that i just tried it and my test program doesnt go above 0.00%, and sometimes 0.01% on my duron 850, I agree that it would be kinda overkill anyway. Still that's not the most practical behavior to sharing rtc between programs, what I meant to say with max speed is that you have, say, 3 apps running, one at 256hz, another one at 512hz and another one at 64hz, RTC can be easily configured to allways respond to the higher timing, while delivering events to the divisors too. Also from what I remember when I used int8 in the old DOS days, you can switch the frequency with no delay involved (and even if there was a little delay, there wont be nearly as much delay as you get with a kernel syscall in some situations) , so programs currently using rtc wont have any sort of bad skip while a new process opens the device. This approach seems to me to be a lot more transparent for the end user and developer than having to use ALSA timing or piping rtc. What do you think about it? I feel like going and trying to implement this on rtc.c and make it selectable via some parameter or proc var.. Juan Linietsky
