Re: [rtl] Networking With RT-Linux

[yodaiken@fsmlabs.com]

On Sun, Nov 21, 1999 at 10:08:43PM -0700, Kulwinder Atwal wrote:
> What you have not told us is how long does it take to complete the 50 mS
> task and the 500 mS task (worst case and average case)?
> 
> The reason I ask is that 50 mS is on the boundary of Linux's
> 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.  

Perhaps the paper you are thinking of described slow 486 performance. 
50milliseconds tasks should be unoticeable -- unless they execute
for a significant time. 
100microseconds should be doable but will show some performance loss for
Linux. 

> 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.

Why? Most hardware drivers are perfectly happy running in nonrealtime mode.
And only things that must be in realtime space should be in realtime space
or else they make the realtime system too slow and complex.

If I got attributions right:
> > Yusuf Motiwala <motiwala@lucent.com> writes:
> > > I think that keeping the networking portion as a part of the non-realtime
> > > task (kernel) running at low priority is not a good idea. Now days, many (most)
> > >
> > > of the real-time systems depending upon the network connectivity. Making
> > > networking stack as low priority task will result  in a non-reliable
> > > communication.

This is not correct. You can still have reliable non-realtime networking.
Only if you have hard realtime limits for networking should you have
problems and in this case there are two RTL ethenet drivers available with
more to come.

> Aleksandar Bakic wrote:
> > I agree, but what can I do until RTL gets some RT networking support?
> > I don't have those Tulip NICs; maybe I can ask managers to buy some...
> > Another problem is that my client programs run on non-RT machines (so,
> > at this point, all I am interested in is a relatively high, stable
> > throughput, not more than that)...

In this case realtime network connectivity generally has little value.
You should be able to get relatively high, stable throughput from the Linux
non-realtime drivers. 

> > My answer to the other people who responded (thanks!) is somewhat
> > similar. I need lossless transfer because I send large images for
> > processing a couple of times per second, and smaller ones (10kB on
> > average) more often (it's not JPEG but some raw image format; JPEG
> > encoding/decoding would be too costly). Based on some previous ATM
> > experience, and other people's experience with 100Mbps Ethernet, I
> > thought I could achieve certain throughput. Now, sometimes I get some
> > reasonable results, sometimes something goes wrong. In particular,
> > what could make a non-blocking "send" (socket) call take 16 seconds???

Something is very wrong with your network. Use tcpdump to analyze.

What network cards are you using? What is the network setup?
Is there a router or firewall?

--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail majordomo@rtlinux.cs.nmt.edu OR
echo "unsubscribe rtl <Your_email>" | mail majordomo@rtlinux.cs.nmt.edu
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/