[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [rtl] Networking With RT-Linux



>>>>> "Yusuf" == Yusuf Motiwala <motiwala@lucent.com> writes:

 Yusuf> I think that keeping the networking portion as a part of the
 Yusuf> non-realtime task (kernel) running at low priority is not a
 Yusuf> good idea. Now days, many (most)
 Yusuf> of the real-time systems depending upon the network
 Yusuf> connectivity. Making networking stack as low priority task
 Yusuf> will result in a non-reliable communication.  Also, may
 Yusuf> systems are designed to provide the connectivity, say
 Yusuf> routers. Ffor such system, this approach is highly
 Yusuf> un-reliable. May be I am wrong, but in that case pls correct
 Yusuf> me.

Yusuf,

In general I agree with that.  I'm not sure what specifically in what
I wrote triggered your comments, though.

To elaborate:

All networking protocols are real time processes.  This should be
rather obvious from their use of timers...

In end systems, if you don't run the networking stuff as real time
processes with good assurance of meeting the deadlines, the
applications on that system will suffer.  If those applications are
not themselves real time critical, that may be acceptable.  (Email may 
slow down a lot, or even require retries, but that may not be a big
issue.  Web browsers or other things that have a user interface are
more critical, because there the ultimate issue is how soon the user
will give up on the application...)

If your application is a real-time task that has networking needs,
then at least the data transfer phase of that protocol really needs to 
be part of the real time system, not part of the non-real-time
background.  You can probably leave connection setup/teardown in the
background, though.  Also, for those applications, you can't just take 
TCP and hope it's ok, you have to understand its dynamics and whether
those are acceptable.  If not, you need to do your own transport layer 
with the dynamics you need.

On the outher hand, as you said, routers MUST be designed as real time 
systems for your network to work properly.  If they fail on their real 
time requirements, the entire network may come apart.  And in
particular, you have to worry about the time bounds on ALL activities; 
it isn't sufficient to make packet forwarding a low latency real time
process while ignoring route calculation/propagation, as some
implementers have done.

	paul
--- [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/