[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-rt
Subject:    Re: [rtl] Timing from the sheduler
From:       Paul Koning <pkoning () xedia ! com>
Date:       1999-01-21 22:01:32
[Download RAW message or body]

>>>>> "Bernhard" == Bernhard Kuhn <kuhn@batian.lpr.e-technik.tu-muenchen.de> writes:

 Bernhard> Wright, Robert B. wrote:
 >> i didn't realize that SCSI interfaces posed a problem.  what kind
 >> of latencies are expected with ethernet and scsi?

 Bernhard> Ethernet: collisions (causes retransmission) and
 Bernhard> transmission errors may occur.  SCSI: seeking may be
 Bernhard> extended by mechanical vibrations or read errors (causes
 Bernhard> re-read) may occur.

 Bernhard> Ok, you may give a definit Worst-Case-Timing for the cases
 Bernhard> described above, but theses timings are >10 times higher
 Bernhard> than the likely timings.  Consequence: the system will be
 Bernhard> much too oversized -> costs increasing.

If your network load is known to be moderate, the 99.99% (pick the
number of 9's you want) timing bound may be perfectly acceptable.  It
depends a whole lot on what your time limits are!

 Bernhard> So people usualy take the likely timings a get in account
 Bernhard> that sometimes deadlines are missed ... (missing data
 Bernhard> frames etc. = soft-RT) Mostly, the incoming/outgoing
 Bernhard> data-rate is much lower than the HD-transferrate, so that
 Bernhard> an hard-RT awareness of harddisks is not necessary (Data
 Bernhard> buffered in memory).

 Bernhard> If you wish to have a better RT-aware
 Bernhard> ethernet-communication, then use point-to-point full-duplex
 Bernhard> connections with directly programming the ethernet-chip. I
 Bernhard> took a look into the (standard)Linux source-code for
 Bernhard> ethernet low-level drivers: it should not be too much
 Bernhard> effort to convert them to RT-Linux drivers.  (So ethernet
 Bernhard> is used on ISO-OSI level 2 instead of ISO-OSI level 4 with
 Bernhard> TCP/IP)

Any kind of point to point full duplex channel eliminates the issue of 
access delay.  Ethernet is certainly a good example.

However, ALL communication channels have non-zero bit error rates, so
you always have a chance (normally very low) of losing a packet.
Almost certainly that will break your real time assumptions.

I think the right way to handle that is to analyze the bit error rate, 
compute from that the packet loss rate, and see if missing your real
time bound that often is acceptable.  

If it isn't, then run multiple channels in parallel, transmit the same 
packet on all of them, and process the first one you receive.  (You'll 
have to be careful with the protocol design here -- good use of
sequence numbers and things like that.)  That will give you
arbitrarily tight bounds.

By the way, running TCP is probably not useful (since retransmission
would be bad for timing) but IP/UDP may certainly be beneficial.  The
overhead is small so you might consider if it adds value for your
case.

	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/

[prev in list] [next in list] [prev in thread] [next in thread]