HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer) (05/25/89)
We have the PCs on campus at Dakota State College networked using IBM Token Ring adapters. The possibility of using Amoeba under Minix seems like it would be a great way to explore multiprocessing, and it seems like it would serve well as a way to get to our Vax, via something like a 386 Minix gateway. I haven't looked too carefully at the Amoeba source, so I am asking if anyone knows whether Token Ring adapter support would be difficult to implement and if anyone has tried it yet. -- Guy Helmer BITNET: HELMER@SDNET Dakota State College AT&T: (605) 256-5315 Madison, SD 57042 (605) 256-6411
scc@cl.cam.ac.uk (Stephen Crawley) (05/27/89)
Amoeba on a token ring would be difficult. Amoeba transaction protocol (TP) relies on (bletch) broadcast to locate an Amoeba service (actually a port) on the network. On an ethernet this will work, though you get problems you have lots of amoeba nodes chattering away. Token rings (and slotted rings) do not support physical broadcasts. This is ONE of the reasons that Amoeba TP is unpopular around here. A few months ago I was talking to CWI people about a broadcast-less version of TP, but that project got put to one side. -- Steve
cire@dustbin.cisco.com (Eric B. Decker) (05/29/89)
In article <760@scaup.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes:
Path: hercules!joyce!ames!hc!lll-winken!uunet!mcvax!ukc!cam-cl!scc
From: scc@cl.cam.ac.uk (Stephen Crawley)
Newsgroups: comp.os.minix
Date: 26 May 89 21:21:25 GMT
References: <16240@louie.udel.EDU>
Sender: news@cl.cam.ac.uk
Organization: U of Cambridge Comp Lab, UK
Lines: 11
Posted: Fri May 26 22:21:25 1989
Amoeba on a token ring would be difficult. Amoeba transaction protocol
(TP) relies on (bletch) broadcast to locate an Amoeba service (actually a
port) on the network. On an ethernet this will work, though you get
problems you have lots of amoeba nodes chattering away.
Token rings (and slotted rings) do not support physical broadcasts. This
is ONE of the reasons that Amoeba TP is unpopular around here. A few
months ago I was talking to CWI people about a broadcast-less version
of TP, but that project got put to one side.
-- Steve
How do you figure that? Token Rings at least the IBM and IEEE 802.5
versions sure do support broadcast. Not that I agree with server
rendezvous using broadcasts in general. But saying Token Rings don't
support physical broadcasts must therefore be an over-generalization.
I figure you must be talking about some other implementation of Token
Ring.
The IBM/IEEE 802.5 Token Ring supports various flavors of group/multicast
addresses. The first is broadcast. A Token Ring interface is required
to recognize either 0xC000FFFFFFFF or 0xFFFFFFFFFFFF as the broadcast
address and accept the packet. The former is for backward compatibility
with early IBM implementations (so I figure) and the later to simplify
some of the problems with Token Ring and Ethernets coexisting and
inter-operating.
Another class of group address is the Group. This is analogous to
multicast addresses on Ethernets. This allows an arbritrary address
within limits to be assigned to the interface. My big bitch with this
one is the chipset I happen to be using only gives you one. Drag city.
Group addresses are in the range 0xC00080000000 to 0xC000FFFFFFFE.
The last class and certainly an interesting one is the Functional
address. This is a bit significant address. That is you can
set you address to say 0xC000 0088 4000 and you will nab packets with the
destination addresses of 0xC00000800000, 0xC00000080000, or
0xC00000084000. You get the packet if any of the bits in the destination
address are also turned on in your functional address.
The Group or Functional address would be real great for server type
rendezvous. The Functional would allow defining groups of servers.
Hope that clears some of the fog.
-c
--
cire|eric
Eric B. Decker
Token Ring Development
cisco Systems - engineering
Menlo Park, California
email: cire@cisco.com
uSnail: 1360 Willow Rd., Menlo Park, CA 94025
Phone : (415) 326-1941scc@cl.cam.ac.uk (Stephen Crawley) (05/30/89)
In <16240@louie.udel.EDU> cire@dustbin.cisco.com (Eric B. Decker) writes: > How do you figure that? Token Rings at least the IBM and IEEE 802.5 > versions sure do support broadcast. I stand corrected. I was generalising from my knowledge of rings (e.g. Cambridge Ring, CFR, etc) that do not support broadcast. So Amoeba on a token ring may be feasible. But don't blame me if your token ring bogs down with floods of broadcast packets :-). Seriously, in the "real" amoeba TP driver and the Amoeba/UNIX version, there is a pathological case where you see a lot of server locate broadcasts on the net. When the server does not have enough threads listening, a client request can arrive when the server is not ready. This causes the TP driver to drop/reject the packet, and the client's TP driver issues a locate. This will often happen when you have a single client thread trying to send a stream of data to a single server thread. One time, someone at Cambridge doing something like this with a handful of client/server pairs managed to bring our ethernet to its knees. My workstation was spending 100% of its time fending off Amoeba broadcasts. -- Steve
sater@cs.vu.nl (Hans van Staveren) (05/31/89)
In article <762@scaup.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes: > >So Amoeba on a token ring may be feasible. But don't blame me if your >token ring bogs down with floods of broadcast packets :-). > >One time, someone at Cambridge doing something like this with a handful >of client/server pairs managed to bring our ethernet to its knees. My >workstation was spending 100% of its time fending off Amoeba broadcasts. > >-- Steve I do not like to react as hurt in my feelings, but there is no way that the current Amoeba software will ever generate a broadcast storm. There is special code to prevent, even in pathological cases like fast client and slow server, the occurence of more than ~20 broadcasts per second. I do not say that this is very little, but it only occurs in pretty strange cases, and it will most certainly not bring an Ethernet to it's knees. Our installation here runs some 40 Amoeba poolprocessors, mostly 68020's, on the same Ethernet as lots of Sun's and various other stuff. Had it been that bad someone would certainly have complained to me. Hans van Staveren Vrije Universiteit Amsterdam, Holland
scc@cl.cam.ac.uk (Stephen Crawley) (06/05/89)
In <2674@sater.cs.vu.nl> Hans van Staveren writes: >I do not like to react as hurt in my feelings, but there is no way that the >current Amoeba software will ever generate a broadcast storm. There is special >code to prevent, even in pathological cases like fast client and slow server, >the occurence of more than ~20 broadcasts per second. I do not say that this >is very little, but it only occurs in pretty strange cases, and it will most >certainly not bring an Ethernet to it's knees. The special code that Hans described to me as code to limit the Amoeba TP driver to sending at most one locate broadcast per (10Hz) clock tick. In other words a single kernel can in theory emit 10 broadcast packets per second. I cannot see how this makes a broadcast storm impossible! Sure a single machine won't do it, but if you write a distributed application that does a lot of communication between a number of machines ... watch out! The pathological cases that Hans talks about that are not at all unusual if you naively try to use Amoeba TP as a "universal" transport protocol as some of the the Amoeba proponents claim you can do. For example if you try to build a niave byte stream on top of TP. This is exactly how the CWI supplied amoeba runtime libraries implement stdio streams! I remember being boggled by how slow single character writes to an unbuffered stream were. Now I think I know why.] >Our installation here runs some 40 Amoeba poolprocessors, mostly 68020's, >on the same Ethernet as lots of Sun's and various other stuff. Had it been >that bad someone would certainly have complained to me. Hans: How many Xerox InterLisp machines do you have? Machines like Suns have decent ethernet interfaces and fast processors and can tolerate a surprisingly high broadcast rate. A Xerox 6085 / 1186 has a wimpy ethernet interface and a slow processor and is badly effected by a relatively low broadcast rate. My workstation is a 6085 ... Also, what sort of parallel applications are you running on your 40 pool processors? Were they written by novices or by people (like you) who knew all about the pitfalls of locates?