[email protected] (R.S.) writes: > Yes, however my curiosity is related only to coax port - coax port > "channel". In this scope any other bottleneck does not apply. Of > course in real word the weakest link of chain is the most important. > BTW: 3174 can be channel-attached, and I guess that ESCON is not a > bottleneck for coax, even 32 of them.
re: http://www.garlic.com/~lynn/2011e.html#94 coax (3174) throughput I never measured 3174 ... the 3274 had the opposite problem ... not only did moving lot of electronics out of the head back to shared control unit ... enormously increase coax cable chatter and slow down thruput (i.e. both the amount of chatter on the coax as well as latency for all the back and forth to support really "dumbed down" 3278) ... but the slow electronics in the 3274 had significant hit on (bus&tag) channel busy (transfer rate 640kbytes on the channel side ... but really slow handsaking made raw transfer rate only small part of the channel busy ... analogous to all the really slow handshaking on the coax side enormously slowing down effective response time and transfer rate). I had done a project for the IMS group when STL was bursting at the seams and 300 were being put at remote site ... with datacenter support back to STL. They had tested "remote" 3278 support back to STL and found it truely horrible and totally unacceptable ... local channel attach 3278 were bad enough having hard time making subsecond response http://www.garlic.com/~lynn/2001m.html#19 3270 protocol but for "remote" 3278, it wasn't even "remotely" possile :-) The side effect of doing support for channel-extender ... allowing "channel" attached 3274s controllers to put at the remote location (and providing 3278 response at remote location, that was indistinquishable from local channel attach), the channel-extender boxes had significantly faster channel interface processing ... getting the 3274s off the real channels improved local processor thruput by 10-15%. When 3278s originally came out ... we complained loudly to the product group about 3278 interactive performance vis-a-vis 3277. Eventually the product group came back with the reply that 3278s weren't designed for interactive computing but for "data entry" (aka basically online "upgrade" for card punch machines). The controller channel busy overhead (independent of raw transfer rate) was to raise its head again with 3090 and 3880 disk controllers (3mbyte transfer rate). The 3880 channel busy overhead turned out to be so high, 3090 product realized that it had to add a whole bunch additional channels ... which resulted in having to add an extra TCM to 3090 manufacturing (there were jokes that the 3090 group was going to bill the 3880 product group for the cost of the increased 3090 manufacturing cost). This was sort of the leading edge of theme that mainframes with enormous number of channels being a good thing (when it was actually to compensate for the channel/controller interface design and slow controllers would drastically reduce channel effectiveness). a couple recent posts: http://www.garlic.com/~lynn/2011.html#37 CKD DASD http://www.garlic.com/~lynn/2011e.html#15 At least two decades back, some gurus predicted that mainframes would disappear in future and it still has not happened -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
