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

List:       linux-rt
Subject:    Re: [rtl] Beowulf and RTLinux (and NIC latency)
From:       David Olofson <david.olofson () reologica ! se>
Date:       1999-09-28 10:37:46
[Download RAW message or body]

David Schleef wrote:
> IMO, Rether is a good implementation of a poor idea.  At least, it is
> a poor idea in the RTLinux context.  It is a good idea in the Rether
> context.  Keep in mind, also, that Rether is designed for "guaranteed
> bandwidth", not "real-time."  In the soft-real-time world, they are
> much the same.

"Guaranteed bandwidth" can be interpreted as "it must be possible to
transfer a certain ammount of data before a deadline". Soft real time
allows deadlines to be missed - or, the guaranteed bandwidth requirement
not to be met during certain periods of time.

That's not acceptable for high end multimedia systems, as it would
result
in the dreaded drop-outs that make Windows and Mac systems rather
useless
in live situations. That is, the systems I have in mind require "hard
guaranteed bandwidth". It *does* mean that there has to be some form of
compromise between average latency and bandwidth, but as long as the
*maximum* latency is bounded, we're still dealing with hard real time,
at least according to the definitions I know about...

[...]
> Moreover, non-real-time hosts cannot participate in a peer-to-peer
> token passing Rether, _even if_ they understand the protocol.  The
> reason is because there might be another RT host that relies on
> the non-RT host releasing the token in a specified amount of time,
> which cannot be guaranteed by the non-real-time host.

Or; real time drivers are *required* on all hosts on the real time
net. I hardly think you can avoid that without building the protocol
into the hardware, or using a separate non-RT network.

> A client-server token passing scheme, I think, would solve these
> problems.  The reliability of the network would only depend on the
> token server.  Non-real-time systems would also be able to send
> packets on the network, as long as they obey the "time window"
> requirements set by the token server.

A bit more reliable, perhaps, but the non-RT systems still have to
use RT drivers, or they may fail to stay within the time window they
get from the token server...

> I wouldn't be surprised if the Rether people implemented and
> wrote about client-server token passing, but I never found anything
> on their web site or in the literature.  Someone should check.

Haven't seen anything on that either, IIRC.


//David
--- [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]