On Mon, Sep 27, 1999 at 04:23:45PM +0200, David Olofson wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Depends on what you want to do. I think RT/Beowulf is a natural combination
> > for systems where, for example, one needs a supercomputer level of
> > visualization or simulation connected to RT control.
>
> And while we're on the Beowulf subject; what's the latest news in the
> network
> drivers/RTLinux area? I have seen some interesting documents on RETHER,
> but
> I'd like to see some more figures on actual transfer rates and latencies
> that
> can be achieved with RTLinux drivers.
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.
Rether, for those who do not know, builds a token-passing
layer between the ethernet hardware and then uses token passing to
moderate each host's use of the ethernet. It is much like a parliament,
where each speaker must have the "floor" -- each host must have the
"wire".
However, they designed and implemented a peer-to-peer token passing
scheme, where each host is responsible for maintenence of the token,
such as "Who gets the network and when"-type information. Also, one
of the design requirements (for them) was to be able to pass
non-real-time packets over the Rether, which might not be a design
requirement for a hard-real-time system because of the overhead
involved. (It would be nice, however, to be able to have single-
wire RTLinux hosts.)
For hard-real-time networking, peer-to-peer token passing is a bad
idea, since it imposes a significant overhead at real-time priority
for all hosts for token maintenence -- increased complexity when
trying to design systems. Even worse, failure of any host means
failure of the network, since correct token passing relies on all
hosts. Recovery of the Rether token appears to be one of the
major difficulties that the Rether research group solved.
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.
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.
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.
dave...
--- [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/
