Device and channel 364
escon was also half-duplex (maintain compatibility with bus&tag?) and frequently is rated at 17mbytes-sec (aggregate) ... the half-duplex characteristic then also made effective thruput sensitive to distance latency.
escon had been laying around pok for quite a while before it got out (some of it possibly dating back to when my wife did her stint in POK in charge of loosely-coupled architecture).
one of the austin engineers had taken much of the escon spec, turned it into full-duplex, up'ed its thruput by about 10% to 220mbits-sec, and converted to much less expensive optical drivers. this was available as "SLA" (or serial link adapter) on original rs-6000.
then he started work on upgrading it to 800mbits-sec. at that time my wife and i had been doing some stuff with LLNL with respect to their filesystem in conjunction with cluster operation
which eventually became a product called unitree (we also spent some time with ncar on mesa archival and some number of other locations that had developed cluster environment filesystem support).
in that time-frame LANL was doing work to standardize cray channel as HiPPI, LLNL was trying to standardize some serial-copper technology they were involved in as fiber channel standard, and slac was backing fiber SCI (scallable coherent interface).
we helped convince the SLA engineer to give up the 800mbits-sec SLA and go to work on FCS standards commitee ... where he quickly became the editor of the FCS standards document. FCS started out being 1gbit full-duplex (simultaneous in each direction, 2gbit aggregate, as compared to escon's 200mbit half-duplex).
Yes, when I was working on PEX (PHIGS Extension for X) at IBM, we had a...
He Who Thought He Knew Something About DASD 367
in the reference about supporting a couple hundred IMS people moving from bldg.90-STL to a location about 10 miles away: ... a similar configuration was installed when the FE IMS service people in boulder...
full-duplex operation not only provided twice the aggregate thruput (compared to half-duplex operation), but most of the full-duplex protocols also involved asyncronous operation ... which significantly mitigated any long-haul latency that might be involved in some FCS deployments.
later some number of POK channel engineers become involved in the FCS standards effort and there was lots of contention (mailing list as well as meetings) were they were attempting to map traditional IBM half-duplex device I-O operation on top of native asyncronous operational environment (for one thing, state that was expected is be preserved in an half-duplex environment is prone to being reset in a full-duplex, asyncronous environment).
total SLA business trivia ... we had an interesting business problem with SLA ... trying to convince other vendors to incorporate SLA hardware into their products (and allow interoperability with rs-6000). Turns out that there is an internal business process between locations about transfer of pieces (in this case the SLA chips) that resulted in an N-times cost multiplier.
Unfortunately from the plant producing the SLA chip to outside vendors there was three internal location transfers ... with each location following the internal business process transfer rules which resulted in a 3*N-cost multipler for SLA chips to outside companies.
random past posts mention escon, ficon, fcs, sci, hippi, etc: