Path: 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 * ... * 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.