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.  

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.

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.

You can also do the following:

Reduce the workload on normal Linux.  Shutdown any daemons, and other
background tasks that are not absolutely essential. If you are sending
JPEG then I suspect that you may be running X and some X apps.  If you
can do with out X or some of the X apps try it. Also, even if you can't,
try it anyway just to verify that this is the problem.  Test this
hypothesis by running just the RTL and console mode Linux with no apps,
daemons, or other background tasks running on both the sender and
receiver.  If you have successfully ruled out network congestion and
buffering, then I suspect the reason that it sometimes takes 16 secs to
send your data is because some Linux tasks (maybe kernel level daemons)
are intermittently becoming active and competing for resources.  If this
is not the cause then at least by following the above procedure you can
rule it out.

Also, the system command 'ptree' will list all of the processes
currently running.

- Kal.

Aleksandar Bakic wrote:
> 
> Yusuf Motiwala <[EMAIL PROTECTED]> 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.
> > Also, may systems are designed to provide the connectivity, say routers. Ffor
> > such
> > system, this approach is highly un-reliable. May be I am wrong, but in that
> > case pls
> > correct me.
> >
> > Regards,
> > Yusuf
> 
> 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)...
> 
> 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???
> (I used the TCP NODELAY option to make it non-blocking. Is there a
> better one?) I've been getting different results with different
> machines as senders and receivers; so far, not so good.
> 
> Thanks,
> Aleks
> 
> --- [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/
--- [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/

Reply via email to