Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!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: <209@gvlv2.GVL.Unisys.COM> Date: 24 Apr 89 15:01:03 GMT References: <407@bnr-fos.UUCP> <17500@obiwan.mips.COM> <17527@winchester.mips.COM> <25241@amdcad.AMD.COM> <199@gvlv2.GVL.Unisys.COM> <1989Apr22.225625.5883@utzoo.uucp> <25368@amdcad.AMD.COM> <208@gvlv2.GVL.Unisys.COM> Distribution: usa Organization: Unisys Great Valley Laboratory Lines: 93 Sorry for the doublepost folks, our news-responder has a problem with building response files. In article <25368@amdcad.AMD.COM> ching@pepsi.AMD.COM (Mike Ching) writes: * In article <1989Apr22.225625.5883@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: * >In article <199@gvlv2.GVL.Unisys.COM> kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) writes: * >>...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... * > * >Are you familiar with Chesson's "protocol engine" work? He's looking at * >a fully general virtual-circuit protocol that can keep up with 100Mbps FDDI. * >Yes, it's done in hardware. The protocol is carefully organized so it can * >be processed "on the fly", i.e. the hardware can keep up with 100Mpbs * >indefinitely, not just in bursts, provided there's somewhere for the data * >to go at that speed. * * Actually 100Mbits is the low end of the range being addressed by the protocol * engine. The intent is to have a protocol and hardware that can support future * gigabit networks as well as the current 100megabit one. Yes, we have seen some of Chesson's work, and similar work including some being done wlsewhere in Unisys. And there are two key differences (undermining assumptions?) between those works and what we are trying to do... - 1) "fully general" We are not attempting, and do not particularly want to achieve, a network to handle "the general case". Our objective is to interconnect VERY high-speed, VERY high-volume, VERY high-load [hosts]. The immediate case is a campus-scale set of supercomputers and associated peripherals [storage or source or sink or interaction] communicating at something close to as fast as they can compute. Now 100 MFlop/sec at (only?) 32 bit/number is 3.2 Gbit/sec. Which is not quite yet what these systems _sustain_ for _many_ seconds, but that is our target range. Refer to current work on "computational visualization", and similar ideas, then consider _numerous_ "visualization workstations" and _several_ or more "primary computational engines". - 2) "virtual circuit" The virtual circuit concept, as usually interpreted and applied in networks of extremely many endpoints, is necessarily (?) part of any general case approach, but unfortunately carries unnecessary baggage in both the intellectual and practical senses. (did I say that right?) We do, necessarily, have a concept of "circuit", at least to the extent that there is an established and finite agreement between two end points to exchange information. And our concept of a circuit is "virtual", at least to some extent, in that not all segments of the intervening signal media are irrevocably and uniterruptedly dedicated to the particular circuit or session, or that on two disjoint occasions, an apparently same circuit between a given pair of end points may utilize different signal paths. ------- We view a transaction as involving at least a MegaByte, and well likely numerous MegaBytes of data in at least one of the two directions of the circuit. And we view a session as involving numerous to numerous _hundreds_ or even _thousands_ of transactions. So a session easily approaches several to numerous GigaBytes of traffic or more, and becomes many to very many seconds in duration. ------- In the case of "vizualization", or the more general case of "process distribution", or the worse case of "coupled computations", there are also the elements of "timeliness" and "computational compactness". --Timeliness applies to things like step-results (e.g. arrays?) (large chunks) which must be moved from one process engine/locus to another with enough expediency (?) that the receiver will always find its next needed input ready to be used. Timeliness also applies, maybe even more critically, when the unit intermediate result is not so large. That is, a megaword intermediate array may admit some significant buffering for some processes but a 20-word unit vector probably needs to "get there now" and "be used immediately" so that a return result and "be returned PDQ". So the idea of timeliness runs head-on into things like packet-delay or channel-access-latency or acknowledgement-turnaround--in terms of what has to happen "inside" the "network space" and also in terms of how much computation the sender or receiver has to devote just to sending and receiving instead of "useful" computing. --Computational compactness applies to things like array-like or whole-image-like or file-like transaction data units, in that none of the unit is useful to the receiver until all of the unit has been received, or that the sender cannot compute the next unit until the now completed unit has been sent. So even if we can move data a fair bit better than the long-average computation rate, we end up losing a lot of very expensive computation engine cycles waiting for these bunches of data to "get here" of "get gone". --The concepts of shared networking, shared channel media, virtual circuits sharing physical route segments, etc., running everything at levelled or average rates, even aggregated onto very high-speed facilities, end up having a backlash effect that EVERYTHING, END-TO-END, ends up being shared and multiplexed and multiprocessed and levelled. Which ends up, at the very least, with an awful lot of overhead spread across the realm or concentrated in a couple of bottlenecks--but still a lot of overhead and, worse, logical complexity which we think is unnecessary. --------- So, anyhow, that's enough for one diatribe disguised as a tutorial. --- Regardz, Ken