On Tue, Nov 03, 1998 at 07:50:45PM -0700, Vassili Leonov wrote:
> Hello,
>
> I'm working on a kernel driver (module) for supporting video capture and
> playback PCI board with hardware MJPEG compression
>
> ( http://pcisys.net/~vleo/linuxvideo.html )
>
> Board works by transferring data (about 100k) into a buffer and issuing
> an interrupt, there are 4 buffers in a ring. Every field compressed gets
> a field sequence number.
>
> When I don't touch anything fields are not lost, but as soon as I start
> touching X11 windows, I'm getting several frames dropped. Since frames
> are coming at a rate of 60Hz, and there are 4 buffers, if interrupt is
> not serviced within 64 msec frame would be lost. First of all - is this
> normal for Linux to have a latency over 50msec, or something else is
> wrong on my system (K6,233MHZ).
>
> Second question would be - do you think that RTLinux is the solution to
> this kind of problem. Note, it's not enough to service interrupt within
> 64msec, I also need to transfer the data into the application that is
> reading from the driver. The total rate is about 3.5Mb/sec for the least
> degree of compression. One of the simple ideas that comes to mind is to
> create a BIG ring of buffers elswhere, say 20-30 of them in the hope
> that Linux kernel would be quick enough on the average.
If the application that is reading the data is at regular priority, then
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.
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 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...
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
