>>>>> "John" == John Ford <[EMAIL PROTECTED]> writes:
>>...
John> <lots of very good info snipped>
Thanks!
>> ...
>> 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.
John> This is the crux of the matter. I agree totally with you that
John> it can be made to work *most* of the time. This is not
John> consistent with hard real time systems that must meet the
John> deadline *every* time. If meeting the deadline most of the
John> time is sufficient, then I claim that the standard Linux
John> scheduler system combined with a very fast computer will get
John> you there.
Yes, if your requirements are loose enough, then the standard
scheduler will work. To find the answer you need numbers...
>>....
>> Better yet, consider running two networks, thereby physically
>> separating the real time traffic.
John> This is our approach. The software running on 2 machines is a
John> master-slave type system, so collisions and interference
John> between the 2 users of the network are eliminated.
A full duplex connection would do the same thing.
But there's still an issue that remains. You mentioned that a hard
real time system "must meet the deadline *every* time".
Such systems don't exist, because all hardware has non-zero failure
rate, and some of those failures will make you miss the deadline. So
what you actually have is a system with a failure rate less than X,
where X is chosen so the rate of failure is low enough given the
consequences of failure. The right value of X is of course
application dependent... And it may not have been chosen explicitly,
but it's certainly always there.
Networks are just a part of this system. If you're passing messages
around, presumably loss of messages will cause failure (missed
deadline, or whatever). Perhaps you're using retransmission, or
redundant wires; if so, loss of N consecutive messages causes failure
(for some N). Again, these rates can't be zero. However, for many
network types they can be measured or analyzed, and you can observe
the operation of the actual network to verify that it is behaving as
planned. You need to determine what message loss rates are acceptable
(from the value of X as defined above), and relate those to the
properties of the chosen network. Depending on the numbers, a simple
network may do, or you may need to segregate real time traffic to
dedicated wires, perhaps use duplicated networks, or retransmission,
or FEC, or combinations of these.
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/
