🚀 go-pugleaf

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