rich@eddie.MIT.EDU (Richard Caloggero) (02/24/88)
We have recently purchased an Alliant fx8 and are planning to
configure a heterogeneous environment based on 9 Apollo dn3000s,
and the fx8. Are focus is on computational mechanics, and thus we need
an environment which is flexable, easy to use from the vewpoint of an
engeneer, and adaptive to the changing technology. My question is
this: what are the advantages/disadvantages of replacing our domain
ringnet with ethernet. If we go with our current plan of using one of
our 3000s as a gateway to the ethernet on which there exists only one
host, the fx8, is it probable that this might become our bottleneck in
the future, especially since we don't have the resources to dedicate
one Apollo exclusively to the task of being a server; they will all be
used interactively? Also, is domain/os, since it is more Unix-like,
more comfortable running in a native ethernet environment?
Any comments or experience with either configuration, or
suggestions of other configurations are most welcome. Thanx in
advance.
--
-- Rich (rich@eddie.mit.edu).
The circle is open, but unbroken.
Merry meet, merry part,
and merry meet again.mishkin@apollo.uucp (Nathaniel Mishkin) (02/24/88)
In article <8242@eddie.MIT.EDU> rich@eddie.MIT.EDU (Richard Caloggero) writes: >My question is >this: what are the advantages/disadvantages of replacing our domain >ringnet with ethernet. If we go with our current plan of using one of >our 3000s as a gateway to the ethernet on which there exists only one >host, the fx8, is it probable that this might become our bottleneck in >the future, especially since we don't have the resources to dedicate >one Apollo exclusively to the task of being a server; they will all be >used interactively? Also, is domain/os, since it is more Unix-like, >more comfortable running in a native ethernet environment? Using an Apollo attached to an Ethernet is virtually no different using one attached to an Apollo token ring. It just works. DOMAIN/OS has no bearing on the matter, because it's worked for some time. The only differences arise from different intrinsic properties -- e.g. on an ring net, a sender of a message can sometimes get information back about the state of the receiver in the same time it takes to send the message; this isn't the case on an Ethernet. The result is that there are some cases on a ring net where a sender can immediately determine that some remote machine is (say) down, whereas on an Ethernet, the sender has to go through some software-driven timeout/retry scheme. In an installation that already has machines on an Ethernet, putting your Apollos on the Ethernet can be only a plus. Apollos on a ring are guaranteed to have to go through at least one gateway to get to your other machines. Apollos on an Ethernet will be able to talk to other machines on the same Ethernet directly. -- -- Nat Mishkin Apollo Computer Inc. Chelmsford, MA {decvax,mit-eddie,umix}!apollo!mishkin
krowitz@mit-richter.UUCP (David Krowitz) (02/27/88)
We have our Apollos on a ringnet which is gatewayed into our departmental ethernet. While this does slowdown the communication rates between machines on the ringnet and machines on the ethernet due to the hop through the gateway, it's not really noticable in many cases (ie. running TELNET). There are some advantages to this configuration. There are a bunch of diskless Suns on the departmental ethernet. When a few of them start page thrashing, the ethernet gets pretty bogged down. Sometimes it get completely jammed and we can't connect to any of the machines on the ethernet. The machines on the Domain ringnet are completely unaffected since the gateway isolates us from the problems on the departmental ethernet. If the ethernet were completely under our control this wouldn't be a problem, but since we have to wait to have someone else fix any problems on the ethernet having the gateway is a *great* blessing. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu mit-erl!mit-richter!krowitz@eddie.mit.edu mit-erl!mit-richter!krowitz@mit-eddie.arpa krowitz@mit-mc.arpa (in order of decreasing preference)