🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #20817

Re: One aspect of bandwidth (backplane bus)

#20817
From: Ken Leonard
Date: Mon, 17 Apr 1989 13:34
62 lines
4726 bytes
* ... 
* FDDI-speed components that could be used in a super-simple "external serial 
* backplane" based on point-to-point links. For example, consider AMD's "TAXI" 
* ... 
* This is "only" 12.5 Mbyte/sec per channel, but you could have many of 
* them, even one per device. Note for comparision that even the fastest 
* ... 
* I'd certainly like to see an El Cheapo fiber-optic I/O bus ("Cheap-O-Bus"?), 
* ... 
* Something along the lines of a 100 Mbit/s Starlan or 10baseT, that is, 
* active hubs or concentrators (unless only two ends) with point-to-point 
* links to CPUs or devices. 
* The trick is in keeping the design (and link protocol) cheap enough that 
* you could have "100baseF" disks and other peripherals the same way you have 
* SCSI disks today. And of course, it could *also* be used as an LAN, much 
* the same way "370"-like mainframes use Channel-To-Channel adapters today. 
* (FDDI is supposed to so this, but it looks too expensive/complex to me. And 
* do you really need 1300nm light so you can put your disks two kilometers away?) 
* Anybody interested? 
We (Unisys Defense Systems, NIS/SSE) are presently building a first cut at a 
very high speed local-like bus-like lan-like thing. For reasons not necessarily 
very good, it is (probably unfortunately) called Very High Speed Local Area 
Network (VHSLAN). The very first implementation, four CPU nodes, is to be up 
and running late this year. We are aiming at 40MByte/sec to prove the pieces 
work, and about 120MByte/sec to deliver next year. These are "real" "net after 
all overhead" "really uninterrupted indefinitely continuous" data rates. The 
rates apply per node-to-node path, regardless of the number of paths 
concurrently operating, including the case of every node in the network 
concurrently talking to some another node. The ostensible application is 
"supercomputer" memory-to-memory megablock transfer or continuous streams, 
although we generally tell those who sign the chits that it's "file transfer" 
or similar too-restrictive terms. We haven't completely figured out how to deal 
with the "where-to-send-this-piece" info for a given "block" as fast as we can 
move the piece--that is, even with darnnear no protocol, we can't get away with 
absolutely no protocol, and any protocol has to be "figured out" and "acted on" 
by something inside the net and that something, so far, looks like it still has 
to be electronic logics. Of course, a degenerate, strictly two-ended 
implementation or a dedicated ring (SuperCPU process distribution?) wouldn't 
need decisions by the net since it wouldn't be a net so it could really run at 
full rate all the time. And then, a smart-enough disk-bank controller thing 
which made the platter space look like a flat memory space might be 
interestingly sharable/interleavable across a processor cluster. And there are 
a few other ways we think it might be useful. Now 40MB/s or even 120MB/s is no 
contender for CPU-bus-of-the-year when compared to rates between a SuperCPU and 
its own corehouse or its own tightly coupled disk bank or its busplane-coupled 
twin neighbor. But it looks pretty good, we think, as an arbitrarily 
configurable routeable directable interconnectable "full performance at full 
concurrency" LAN-like thing for a cluster or assemblage or campus full of 
SuperCPUs and their consorts. And, after all, we are talking about these rates 
per single-conductor connection, with _n_ conductors in parallel per "channel" 
_not_ nearly _n_ times as expensive as one per channel. It is also probably 
going to be affordable, and maybe even economically justifiable. We are doing 
all this because, among other things, we think that busplane-derived 
architectures _are_ just about at their limit and both the problem-program folk 
and the system-architecture folk are going to _have_ to really work at process 
distribution or problem segmentation or computational load sharing--none of 
which are really the same as parallelism, necessarily. 
 
Ken Leonard 
--- 
This represents neither my employer's opinion nor my own--It's just something 
I overheard in a low-class bar down by the docks. 
Technical Details
Message-ID: <199@gvlv2.GVL.Unisys.COM>
Path: arc1-ca.pugleaf.net!utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!gatech!udel!burdvax!gvlv2!kleonard
References: <407@bnr-fos.UUCP> <17500@obiwan.mips.COM> <17527@winchester.mips.COM> <25241@amdcad.AMD.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!gatech!udel!burdvax!gvlv2!kleonard
From: kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard)
Newsgroups: comp.arch
Subject: Re: One aspect of bandwidth (backplane bus)
Message-ID: <199@gvlv2.GVL.Unisys.COM>
Date: 17 Apr 89 13:34:02 GMT
References: <407@bnr-fos.UUCP> <17500@obiwan.mips.COM> <17527@winchester.mips.COM> <25241@amdcad.AMD.COM>
Distribution: usa
Organization: Unisys Great Valley Laboratory
Lines: 62