Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!agate!bionet!apple!bloom-beacon!tut.cis.ohio-state.edu!ukma!gatech!hubcap!grunwald
From: grunwald@m.cs.uiuc.edu
Newsgroups: comp.parallel
Subject: Re: Wormhole Routing
Message-ID: <3462@hubcap.UUCP>
Date: 7 Nov 88 18:56:30 GMT
Sender: fpst@hubcap.UUCP
Lines: 28
Approved: parallel@hubcap.clemson.edu

Actually, the iPSC/2 doesn't use worm-hole routing, it uses blocking ecube
circuit switching.

Wormhole routing, in the defn. by Athas & Seitz, consists of sending small
packets (flits) through a network. When your message acquires a link, it
owns it until the last flit passes through. If you can't acquire a link,
you sit there until you can.

Routing and packet forwarding is all done by autonomous routing units. There
is no impact on the computation processor. The Ametek 2010, Mosaic and
Jellybean machine use this routing/switching method.

Drawbacks are: fixed path routing (needed for deadlock free communication),
	although this is being fixed by an adaptive variant.

Basically, the iPSC/2 use a similar method, but it establishs an end-to-end
circuit for the the message, sends the message and then tears down the circuit.
Analysis of this method with the former would show you that it differs
only in the circuit tear-down time, assuming that your message is sufficiently
long that you can't hold the entire message in the network routing units.

Drawbacks: again, fixed path routing. Also, wormhole would work better for
	   short messages or networks that have more buffering space at
	   each routing unit.

In a hypercube architecture, circuit switching messages using the standard
``ecube'' routing method leads to skewed resource utilization. E.g., you'll
find 80% utilization of channel #0 but only ~10% utilization of channel #6
because of the routing algorithm.