Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!mintaka!mit-eddie!uw-beaver!Teknowledge.COM!unix!hplabs!hp-sdd!ncr-sd!ncrcae!hubcap!Donald.Lindsay
From: Donald.Lindsay@MATHOM.GANDALF.CS.CMU.EDU
Newsgroups: comp.parallel
Subject: Re: scalability of n-cubes, meshes
Message-ID: <7252@hubcap.clemson.edu>
Date: 30 Nov 89 13:37:59 GMT
Sender: fpst@hubcap.clemson.edu
Lines: 16
Approved: parallel@hubcap.clemson.edu


One recent poster suggested that hypercubes and meshes had the same
routing latency per hop. I don't agree: wider is faster.  The reason
is that the routing hardware at each node cannot make a decision
until it has seen the entirety of the packet header.  On an NCUBE-2,
the header is 32 bits, sent serially: the latency is 32+ bit times
(44, to be precise). A byte-wide path, such as BBN uses, could make
the same decision in 4+ clocks. (And both could be faster if the
header's likeliest command mode was decodable from, say, the first
half of the header.) 

This particular latency is often dominated by the message time.  But,
it's the kind of point that designers have to be sensitive to.


Don		D.C.Lindsay 	Carnegie Mellon Computer Science


Brought to you by Super Global Mega Corp .com