Mark Hahn wrote:
>[snip]
>pretty gross. the reason is that it's not reasonable to use
>interrupt-based timers for anything close to a 200ns wait,
>(since programming a timer costs O(1us).) therefore, this kind
>of hardware requires either busy-waiting (eating 200ns each op),
>or using the existing timer, which is 100 Hz in normal kernels
>(faster in 2.5, and can be altered if you wish).
>
>
Raising it up don't make the kernel scheduler itself take up too much
time? In my application it won't bother too much since there are
presumably not many competing tasks, but I could only think in
fine-tuning the kernel as a last resort, since the idea is allow it to
run fine in customer's kernel, preferably any version/series...
>
>
>>We wrote a program which accomplishes this by doing outb() to
>>appropriate address(es), followed by usleep(1), but that seems to take
>>about 10 ms at average or so, which is far from good for our application.
>>
>>
>
>what's your target rate?
>
>
The hardware is quite asynchronous, I need to get as fast as possible,
but I guess my least acceptable average case would be something like a
half milisecond or so.
>>I read somewhere that putting the process in real-time priority could
>>lead the average to 2ms, but I had this though that I could solve this
>>by using rdtsc instruction, because as far as I know it won't cause a
>>trap to kernel mode, which maybe expensive, am I right?
>>
>>
>
>you can easily busy-wait using rdtsc. I do this all the time in
>my realtime video code for presenting psychophysiological stimuli.
>(it often polls the video retrace register, as well.)
>
That was the original idea...
>you don't need RT prio to do busy-waits on rdtsc, though you will
>naturally get preempted sometimes. if you do use RT prio,
>then you can always do at most 200ns, and this might wind up
>being more efficient (depending on what else the system's doing.)
>
>
>
I was mentioning the non busy-wait case (usleep), but that don't seemed
good enough at first anyway.
I could live up with preemption, because it happens very seldom (viewing
from this application perspective), but if I can avoid that, it's even
better :-)
>I do something like this:
>
>
>
Exactly what I was looking for, I'll experiment some different
approaches, but the main idea is just that.
Thanks!
Alexandre
-
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/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:20 EST