At 01:05 AM 14-01-99 +0100, Bernhard Kuhn wrote:
>Wright, Robert B. wrote:
>
>> i didn't realize that SCSI interfaces posed a problem.
>> what kind of latencies are expected with ethernet and scsi?
>
>Ethernet: collisions (causes retransmission) and transmission errors may
occur.
>SCSI: seeking may be extended by mechanical vibrations or read errors
>(causes re-read) may occur.
>
>Ok, you may give a definit Worst-Case-Timing for the cases described above,
>but theses timings are >10 times higher than the likely timings.
>Consequence: the system will be much too oversized -> costs increasing.
>
>So people usualy take the likely timings a get in account that
>sometimes deadlines are missed ... (missing data frames etc. = soft-RT)
>Mostly, the incoming/outgoing data-rate is much lower than
>the HD-transferrate, so that an hard-RT awareness of harddisks is
>not necessary (Data buffered in memory).
>
>If you wish to have a better RT-aware ethernet-communication, then
>use point-to-point full-duplex connections with directly
>programming the ethernet-chip. I took a look into the (standard)Linux
>source-code for ethernet low-level drivers: it should not be
>too much effort to convert them to RT-Linux drivers.
>(So ethernet is used on ISO-OSI level 2 instead of ISO-OSI level 4 with
>TCP/IP)
>
>
>Comments?
>
>--
> -------------------------------------------------------------------
>| Bernhard Kuhn (kuhn[at]lpr.ei.tum.de) O|||OO||OO| |
>| Laboratory for Process Control and Real-Time Systems O|||O|O|O|O |
>| Technische Universität München Tel.+49-89-289-23732 O|||OO||OO| |
>| 80290 München, Germany Room 3944 Fax -23555 OOO|O|||O|O |
> --------------------------------------------------------------------
>
Ethernet and IP resume to a "best effort service" because the data link
layer does nothing about error recovery. IP depends on TCP for that.
UDP depends on the application itself. Timing delays are a function of
network traffic. Ethernet was not designed for real time applications.
I have been using ARCNET for the last 15 years and still depend on it.
However, as a matter of policy, I have never designed a control system
that depends on the functionality of the network. It's ok if a printer
get's cut off. It's ok if a operator remote interfacte station get's cut
off. I like to see all the IO os a sub-system directly connected to a
single processor. Urgent action can therefore be taken despite the network.
Driver manipulations are possible, and indeed I have done so myself (the
temptation is great because TCP/IP imposes a heavy overhead). However,
this flight away from standards is a short term gain at the expense of long
term support and portability.
_______________________________________________________
Pierre Cloutier
Tel: (514)-659-9186 Fax: (514)-659-0014
POSEIDON CONTROLS INC
_______________________________________________________
--- [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/
