re: http://www.garlic.com/~lynn/2012o.html#25 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
attached is item from today I did in linkedin mainframe ... work I had done for channel extender in 1980 then also start to show up for fibre-channel in the late 80s. Then nearly 30yrs later (after the 1980 work), TCW does some similar stuff for FICON ... resulting in about three times improvement over original FICON ... and starting to come a little closer to the base fibre-channel in throughput. Part of the issue is that as bit transfer rate increases ... say go from about 16mbits/sec to 16gbits/sec ... a factor of thousand times ... w/o a corresponding increase in block size (say from 4kbyte to 4mbytes) ... transfer time per block decreases by a factor of thousand and end-to-end latency begins to play increasingly significant role. original 1988 fibre-channel started to address with totally asynchronous operation (between outgoing commands packages and returning results). the attached references both faster controller reduces channel busy and (implies) download channel packages as single operation to remote end as part of channel extender and latency compensation (reduce/eliminate number of end-to-end operations & latency for commands and data transfer i.e. somewhat TCW implementation for FICON). a variation on the channel busy shows up with the extremely slow processor in the 3880 controller and 3090 channels. The 3880 channel busy time for disk operation was significantly larger than anticipated by the 3090 group ... to compensate they had to significantly increase the number of channels ... which added TCM and increased manufacturing costs (there were jokes about 3090 group billing the 3880 group for the increased 3090 manufacturing cost ... so it came out of 3880 profit margin, not 3090 profit margin). The significant increase in 3090 channels (to compensate for slow 3880 processor and high channel busy) contributed to the myth of all those channels contributing responsible for higher aggregate I/O throughput (they did, but not in the sense that marketing was trying to imply). from linkedin mainframe: thorton & cray did the cdc6600 ... cray went on to found cray research and thorton went on to found network systems (along with a couple other cdc engineers) ... which produced HYPERChannel. In 1980, IBM's STL was bursting at the seams and they decided to move 300 from the IMS group to off-site building. The IMS group had tested remote 3270 support (back into STL datacenter) but found it totally unacceptable (they were use to vm/cms local channel attached 3270s ... significantly better than mvs 3270 of any kind). I got dragged into doing HYPERChannel "channel-extender" support utilizing collins digital radio microwave link. This turned out to provide 3270 response indistinguishable from what they were use to (and since the HYPERChannel A220 adapters had lower channel busy than 3270 controllers for identical operations, some of the STL datacenter 370/168s performance improved). This somewhat resulted in becoming the corporate HYPERChannel expert ... for both internal as well as customer installations. I got to go to Network Systems hdqtrs periodically and meet with their top people. Not long afterwards, the FE IMS support group in Boulder was being moved to a new building and were faced with similar options and also chose HYPERChannel channel extender. In that case, optical infrared modems were chosen situated on the roofs of the two buildings. There was some concern of signal loss during winter snow storms ... but the only significant case was small increase in bit-error rate during a "white-out" storm when employees weren't able to get into work. later I did the IBM TCP/IP product enhancements for RFC1044 support. The standard product got about 44kbytes/sec throughput using nearly full 3090 processor. In some tuning tests of RFC1044 support at Cray Research, I got sustained channel speed throughput between 4341 and Cray ... using only modest amount of 4341 processor (about 500 times improvement in the bytes moved per instruction executed). other past posts in this thread: http://www.garlic.com/~lynn/2012l.html#56 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012l.html#57 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012l.html#59 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012l.html#70 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012l.html#81 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012l.html#87 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012l.html#88 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012l.html#90 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012l.html#100 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012m.html#2 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012m.html#3 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012m.html#4 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012m.html#5 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012m.html#6 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012m.html#7 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012m.html#11 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
