Oliver Schindler wrote:
>You're wrong here. The default timeslice is 20 ms, but X or an IDE- IRQ
>can block the system up to 200-300 ms.
Can you please elaborate on HOW (doing what?) can they block the system
up to 200-300ms - and if that is really necessary - or just sloppiness.
I could never understand quite clearly, why, even on Linux running
on PC hardware, if there are several users running gcc at the same
time things become quite sluggish. On the Sun SPARC with same dhrystone
performance numbers - everything is crisp - what's the real hardware
bottleneck on PCs?
>
>>
>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.
Would the FIFO be able to handle up to 4MB/sec stream?
>Now you can use your userlevel process on a high priority to get and compute
>the data.
Actually, the only thing I can dream of is just get it recorded onto the
disk drive, so that it can be manipulated later in the offline mode.
>The thing is that you have to be sure about the average transferrate, the
>rest is handeled by the buffers.
Well,
cp /dev/zero myfile
shows about 4-5Mb/sec on a resonably beefed up system. So I hope the is
average performance to transfer 3.5 Mb/sec.
>> 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.
And what the blip is it - 200-300 ms mentioned above?
Vassili.
--- [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/
