Re: [rtl] IP useage from rtlinux, reply to Richard Teltz

[Paul Koning <pkoning@xedia.com>]

>>>>> "Warren" == Warren Postma <embed@geocities.com> writes:

 Warren>...
 Warren> On one hand if you're using Ethernet, performance is
 Warren> non-deterministic, and even less deterministic over a WAN or
 Warren> the Internet, running the protocol in a high priority RT task
 Warren> would not guarantee deterministic performance.  You say you
 Warren> are using UDP, which means that delivery is not guaranteed,
 Warren> especially on a WAN, meaning that retries must be
 Warren> acceptable. So in that case, what do you hope to gain by
 Warren> porting IP support to the rtlinux kernel level?  You can
 Warren> still communicate between RTLINUX processes between machines
 Warren> by using QUEUES to communicate to a Broker of your own design
 Warren> that then does communications through the network.

 Warren> On the other hand, if you did have hard realtime network
 Warren> requirements and need deterministic performance you could use
 Warren> an ARCNET based system, and then I could see you might want
 Warren> network support inside the RT kernel level.

Warren,

You've repeated the same incorrect information about Ethernet (and
networking in general) that has been circulating ever since token ring 
and token bus were invented.

1. Nearly all networks are nondeterministic in the sense that they
have variable access latency (time for a packet to get to the head of
the queue to when it starts being transmitted is variable).  For
example, in token ring the variation comes from the variable token
rotation.

2. Many networks INCLUDING Ethernet have bounded access latency: the
delay from arrival at head of queue to transmission is bounded.  (For
Ethernet, the bound is 16 worst-case backoffs, which is a few hundred
milliseconds.  For FDDI, it's TTRT times station count, which can be
many seconds.  Don't know what it is for token ring other than that
it's a long time.)

By the way, for full duplex Ethernet the latency bound is zero because 
a packet can be transmitted as soon as it gets to the head of the
queue (no waiting ever).  The same will in general be true for any
point to point datagram network (for example full duplex FDDI).

3. ALL networks have finite loss rate.  The fact that a packet was
transmitted doesn't mean it will be received (with valid CRC, or at
all).  Also, most networks have finite transmit failure rate: the fact 
that a packet gets to the head of the queue doesn't mean it will be
transmitted.  The original question was about IP -- IP does not
necessarily make matters worse.  If you're using IP on one hop (quite
a plausible case) then there's no impact.  If you're using multiple
hops, there might be but if one hop is substantially worse than the
others and the router isn't a bottleneck, then again there is no
impact to speak of.

4. Most traffic is subject to queueing delays.  For some datalinks
(including Ethernet with 802.1<something> priority control) you can
use priority to reduce this IF your hardware actually supports use of
priority for queueing and not just for access to the wire.

5. From your application point of view, the only thing that's
interesting is successful communication.  So you can see that NO
network is deterministic.  If the bounds on transmit delay and
queueing delay are acceptable, you nonetheless have no guarantee of
reception. 

What you can have, given proper design, is bounded latency with some
high probability < 1.  Depending on the system/network, this may
require allowing for multiple transmits with timeout/retry, or even
the use of multiple independent networks with transmits on each in
parallel. 

With all that, it may still make perfect sense to use a real-time
system with any network, for two reasons:

a. You may need it to guarantee your overall system response time
given what your achievable network latency bounds (with probability as 
above) are.

b. You may want to take advantage of the reduced average latency, or
the reduced 98% latency, or some metric like that.  Real-time systems
are generally more responsive in all of those.

	paul
--- [rtl] ---
For more information on Real-Time Linux see:
http://www.rtlinux.org/