> Date: Fri, 28 May 1999 10:55:01 -0400
> From: Paul Koning <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
>
> >>>>> "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.
My point was that it is many times easier and cheaper to re-architect
your application to tolerate the inherent non-determinism in a network
than it is to improve the network to the extent required by the
application.
<lots of very good info snipped>
> 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.
This is the crux of the matter. I agree totally with you that it can
be made to work *most* of the time. This is not consistent with hard
real time systems that must meet the deadline *every* time. If
meeting the deadline most of the time is sufficient, then I claim that
the standard Linux scheduler system combined with a very fast
computer will get you there.
>
> 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.
True. You are stuck before you start, in this case.
> Better
> yet, consider running two networks, thereby physically separating the
> real time traffic.
This is our approach. The software running on 2 machines is a
master-slave type system, so collisions and interference between the
2 users of the network are eliminated.
John
--- [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/
