tom@LOGICON.ARPA.UUCP (05/16/86)
This month's issue (May) of "Mini-Micro Systems" has a blurb in the "Breakpoints" section (page 20) about a system called "Monarch", from BBN Laboratories which will have 8,192 parallel processors of an undisclosed type. In the paragraph they mention that, for those who can't wait for Monarch, BBN is shipping something called the "Butterfly" system consisting of 256 Motorola MC68020 processors working in parallel. Is this any relation to the much-alluded-to "Butterfly gateway" which is supposed to save us from the ravages of brain-dead gateways? Speaking of brain-dead gateways, we have had some more instances of the ICMP "redirect wars". This morning SRI-MILNET-GW redirected us to BBN-MILNET-GW, who redirected us back to SRI-MILNET-GW. This happened 11 times in 29 seconds while trying to establish a connection. A reponse came in 23 seconds, but after we had timed out. Obviously this is sub-optimal... Tom Perrine & Jeff Makey
nolan@MIMSY.UMD.EDU.UUCP (05/16/86)
To set the record straight on Butterflies: The Butterfly processor from BBN has nothing to do with gateways. It is a general purpose parallel processor, configurable with boards to have 16 to 256 processors. It is hosted by a Sun or Vaxen via either an Ethernet or an RS232 TIP connection. Present versions have only MC68000 chips; the MC68020 version is coming shortly. The Butterfly is programmed in C; the operating system is known as Chrysalis. nolan@maryland
leiner@RIACS.ARPA.UUCP (05/17/86)
A little history. The butterfly processor (named because of the interconnection strategy between the multiple processors which is similar to the butterfly of the FFT) was first developed as a voice multiplexer/packetizer for the Wideband Satellite Network project and was called the voice funnel. It was then decided that it would be a good processor for the next generation of gateway and high speed packet switch for the Wideband network. When the strategic computing program started, it was then considered and pursued as a possible architecture for parallel processing in general (as opposed to dedicated use such as a packet switch). The monarch is the next generation of butterfly machine, using more extensive VLSI particularly in the interconnection switching. All of this was done by BBN under the sponsorship of DARPA. Hope this helps. Barry ----------
hinden@BBNCCV.ARPA.UUCP (05/17/86)
The Butterfly Gateway is real and is very related to the Butterfly Multiprocessor. As can be guessed from its name, it runs on the Butterfly Multiprocessor hardware. It was developed by BBN for DARPA and there are currently eleven installed. It is a full function routing Internet gateway with support for 1000 networks. If you would like more information, let me know and I would be happy to supply it. Regards, Bob
CERF@USC-ISI.ARPA.UUCP (05/17/86)
butterfly multiprocessor and butterfly gateway use the same hardware - based on multiple MC68K machines. Monarch is new technology - well over 12 months away, I would guess. Vint
CERF@USC-ISI.ARPA (05/18/86)
John, you leave the impression that the Butterfly Gateway has nothing to do with butterfly multiprocessor! The multiprocessor is indeed a general purpose machine. It has been used by BBN to build a more powerful internet gateway. Clearly, it can be used for other things. Lincoln Labs did a very fast FFT implementation using a 16 processor version, I believe. Vint
gds@SRI-SPAM.ARPA.UUCP (05/20/86)
> From: tom@LOGICON.ARPA (Jeff Makey , Tom Perrine) > Speaking of brain-dead gateways, we have had some more instances of the > ICMP "redirect wars". This morning SRI-MILNET-GW redirected us to > BBN-MILNET-GW, who redirected us back to SRI-MILNET-GW. This happened > 11 times in 29 seconds while trying to establish a connection. > A reponse came in 23 seconds, but after we had timed out. This happens to me also. Here's a sample netstat -r from sri-spam.arpa (10.2.0.107/192.5.38.3). It seems that our default gateway does not always know how to get cross-net ... Routing tables Destination Gateway Flags Refcnt Use SWS pm Interface default 10.1.0.107 UG 0 25 75 0 imp0 su-net-temp sri-milnet-gw.a UG 0 1030 75 0 imp0 su-net-temp isi-gateway.arp UG 0 1027 75 0 imp0 su-net-temp stanford-gatewa UG 0 6071 75 0 imp0 su-net-temp hazeltine-gw.ar UG 0 3 75 0 imp0 su-net-temp sac-milnet-gw.a UG 0 3 75 0 imp0 su-net-temp sri-gw.arpa UG 0 4 75 0 imp0 su-net-temp lbl-milnet-gw.a UG 0 2 75 0 imp0 su-net-temp bbn-milnet-gw.a UG 0 4 75 0 imp0 su-net-temp bbnnet2-arpanet UG 0 4 75 0 imp0 su-net-temp bbn-van-gw.arpa UG 0 2 75 0 imp0 su-net-temp crc-gw.arpa UG 0 1 75 0 imp0 su-net-temp bbn-cronus-gw.a UG 0 2 75 0 imp0 su-net-temp isi-milnet-gw.a UG 0 1 75 0 imp0 su-net-temp sri-csl-gw.arpa UG 0 2 75 0 imp0 su-net-temp bbn-net-gateway UG 0 2 75 0 imp0 su-net-temp dcec-milnet-gw. UG 0 1 75 0 imp0 Note the highest use count for the su-net-temp net is for stanford-gateway, which is as it should be. Some of the other gateways mentioned are a little skeptical -- why would multiple gateways at BBN be involved in what should be a decision strictly made in California? One question is how your host handles redirects. In 4.2, if there are multiple gateways to the same destination, it attempts to share the load between the two, by taking the lowest use count. I have discovered situations in which this may not be ideal. 4.3 attempts to be more flexible by taking the route from the last redirect, and notifying any connections of the route change (this is done in 4.2 BBN also). There is a short time in between the issuance of the redirect and the route change for the connection in which the old route might be used, which could cause a flurry of redirects. I'd like to know how yours (and others) IP routing implementations handle these sort of situations. (I'd especially like to hear from the "hosts should be dumb, gateways should be smart" folks.) Back to the original topic, though, I have noticed similar behavior going between sri-milnet-gw.arpa and bbn-milnet-gw.arpa for a lot of connections I make (aside from the above, this happens for the rutgers and mit-temp networks). --gregbo