If the application that is reading the data is at regular priority, thenYou're wrong here. The default timeslice is 20 ms, but X or an IDE- IRQ
it is subject to the same time-slicing as every other process, including
X. The default time slice in Linux is 200ms. If X uses its entire
time slice, you're screwed.
can block the system up to 200-300 ms.
POSSIX Realtime is not enough here, because it simply works on the scheduler. But if
There are three solutions -- use 'nice -10' and a buffer large enough
to last through the 200 ms (actually more), DMA directly to user space,
or use POSIX real-time to make sure your process gets the time it needs.
I suggest POSIX real-time. RTLinux is not an option, since your problem
is getting data from kernel space to user space, and RTLinux is in kernel
space.
you get IRQ's (Harddisk, network, mouse ..) the scheduler haven't got the slightest chance to schedule the process.
RT-Linux will do a perfect job here, because it will make sure that
you get the data from the IO-Card into the Computer. Then you need a RT-Fifo
which can store 10 to 20 Frames.
Now you can use your userlevel process on a high priority to get and
compute the data.
The thing is that you have to be sure about the average transferrate,
the rest is handeled by the
buffers.
"rescheduled", that's the point .... See above ...
You should also use SA_INTERRUPT when requesting the IRQ, so that your
process gets rescheduled immediately, instead of waiting for a clock
tick.
>
> Is there some code around to measure the latency of interrupts handling
> in regular Linux (2.0.34), and have somebody done a reserach on that?
>Yes. There was a discussion about interrupt latency about a month ago
on linux-kernel. I think the typical latency was on the order of
microseconds, with the occasional IDE-induced blip.dave...
Greets
Oliver Schindler
c/o Robert Bosch Multimedia
