>>>>> "John" == John Ford <[EMAIL PROTECTED]> writes:
John> I hope that we all will agree that there is really no such
John> thing as hard realtime ethernet networking. ...
No. That's an inaccurate statement.
I find myself going over this topic every couple of months,
unfortunately.
What would it mean for a network to be "hard real time"? I can think
of several possible answers.
1. A message offered for transmission will be transmitted in bounded
time or the request will be rejected.
2. A message offered for transmission will be transmitted in bounded
time (and not rejected).
3. A message offered for transmission will be received by its
destination in bounded time.
Ethernet does #1. It sends the packet within 16 worst case backoffs
(about 30 ms on Fast Ethernet) or reports failure. FDDI almost does
#1 but not quite, since recovery from loss of a token doesn't have a
well defined time bound and pending packets remain queued (without
timeout) during that time. I believe Token ring is similar except
that the time bounds are quite a lot larger (FDDI and token ring work
quite differently...).
No network does #2. If you exclude the case of cables being unplugged
and similar physical failure, then there are networks that do #2;
basically, any point to point connection can do this. For example,
full duplex Ethernet does (since the packet at the head of the
transmit queue is transmitted immediately). FDDI and token ring also
do #2 in the shared medium case IF you exclude token loss.
No network does #3, since no network has zero bit error rate.
However, any network can closely approximate #3 (i.e., deliver with a
probability x of packet loss or excessive delay) for quite small x,
given careful attention to bit error rate, congestion (traffic
planning), etc. For some networks it's easier than others. For
example, full duplex Ethernet avoids the excessive collisions problem
at the price of introducing the issue of congestion at the switches.
FDDI and token ring provide a shared LAN that nevertheless guarantees
transmission (#2) if you discount token loss, but if you examine the
worst case delay under very high load you will find the numbers
amazingly high, especially for token ring. For example, an FDDI ring
of 100 stations has a worst case delay of 100*TTRT, and TTRT is
constrained to be at least 4 ms...
If your network load is well below the wire limits, and the network
carries no traffic other than the real time traffic, the job is easy
and Ethernet is a very good solution. Be sure to consider the
consequence of packet loss (due to bit errors), though. A possible
approach is to run dual rails (two independent LANs) with packets sent
on both, and arrival of at least one being sufficient to make things
work. You'll want to have ongoing monitoring of the CRC error rates
to have advance warning of deterioration.
If your network carries both real time and general purpose traffic,
life is hard. Ethernet is more problematic then, but unfortunately
it's not clear there are real-world alternatives that are better. For
example, the FDDI protocol offers solutions but implementations of
those solutions are somewhere between rare and non-existent (and in
any case, FDDI is disappearing). ATM may help but that's an awfully
big and complex hammer. Possibly, running things through routers that
can classify and prioritize traffic may be the best answer. Better
yet, consider running two networks, thereby physically separating the
real time traffic.
paul
--- [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/
