On Sun, 21 Nov 1999, Kulwinder Atwal wrote:
> responsiveness. In a RTL paper I read it said that the responsiveness
> of Linux was in the 30 mSec to 50 mSec range, and that setting RTL tasks
> to execute at less than 50 mSec caused Linux tasks to be noticeably
> affected. Setting RTL tasks in the uSec range like at around 100 uSec (
> if I remember (correctly ) caused Linux to freeze 100 percent.
This was probably with slow 386. On faster processort RT tasks can be run at
around 20 us of even faster.
> I agree fully with the 'priority inversion' problem caused by placing
> the networking at a low priority level in Linux while running RTL.
> Networking should all be in RTL. As should all hardware device drivers.
No. The networking and hardware drivers are of the high priority - they are
in the kernel. RT layer was invented to put something even at higher priority
then the kernel, which disables interrupts from time to time. If you put
networking and HW at RT priority, then soon someone will need Real Real-Time
Linux with additional priority layer. Memory allocation is not time bound -
if you put all device drivers in RT, they should use pre-allocated memory.
Reitarating: the more things you put at RT priority, the worse quality of RT
you will get. RT Linux is for people who work at microseconds time scale.
If you need responsivenes in the range of ms and networking, use other
methods.
>
> Until then you can do the following to help time-critical apps:
>
> - set the privilege for your linux TCP/IP process (your app) to
> superuser
> - read the scheduler function calls in sched.h
> - set linux for round robin scheduling
> - set your TCP/IP process to priority 99 in round robin.
> - set the round robin time slice to a value at least greater than your
> TCP/IP process message send time.
I would add: recompile your kernel with higher value of "HZ" (asm/param.h). I
have a system working for 2 years at HZ=1000. I have used it instead of RT
scheduler (stadard Linux RR scheduling). But since I have noticed that it
sometimes looses the tick at high system loads, I have switched to RT task.
Those are my private opinions.
Best regards,
--
Tomek
P.S. If you send data by UDP, you can not send more than about 50 KB at once
-
you will overflow kernel and card buffers. On the other hand I have no idea
why TCP is taking so long.
--- [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/
