The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Van Dalsen, Herbie) writes: > And who came up with XA I/O? Amdahl, in order to do MDF and share > channels had to do floating I/O interrupts, and related control block > structures in HSA (a la XA) to get this to work. re: http://www.garlic.com/~lynn/2007t.html#75 T3 T3 Sues IBM To Break its Mainframe Monopoly http://www.garlic.com/~lynn/2007t.html#76 T3 T3 Sues IBM To Break its Mainframe Monopoly for other topic drift, a big part of the queued subchannel i/o interface was to compensate for the enormous mvs pathlength to (re)drive i/o ... lots of i/o idle between the end of the previous operation and initiating the next operation. part of this was also predicated that during the 70s, systems started to shift from being significantly processor constrained/bottlenecked to more and more being i/o bottlenecked. i had started pointing this out early ... and at one point some disk division executive assinged their performance group to refute the characterizations (i.e. over more than a decade, the relative disk system thruput had declined by an order of magnitude; aka disks got faster ... but other parts of systems had gotten an order of magnitude faster still). after some period they came back and pointed out that I had slightly understated the problem. this eventually turned into share presentation on how to optimize systems for disk thruput. the initial justification was that the queued interface allowd just moving the redrive operation from mvs kernel into the microcode of the same processor (not even offloaded to different processor), that the microcode engineers could do a significantly better redrive implementation that the mvs software developers. i had worked on a 5-way smp project in 75 where the processor complex had significant microcode capability ... some past posts http://www.garlic.com/~lynn/subtopic.html#bounce and i had defined a queued i/o interface ... but it included being able to offload much of it to a separate/decidated processor. i had also defined a queued microcode interface for dispatching ... allowing processors to pick off work w/o having to go thru the kernel function. this was canceled w/o shipping ... and some of the same people then reconstituted to work on 16-way smp effort mentioned in previous post. i was allowed to play disk engineer in bldgs. 14&15 ... misc. posts http://www.garlic.com/~lynn/subtopic.html#disk and one of the things i worked on was the whole "testcell" testing infrastructure that was being done on stand-alone dedicated machines. They had tried MVS at one point with a single testcell but experienced 15mins MTBF (hangs, crashes, etc, requiring manual intervention and MVS reboot). I undertook to rewrite the i/o supervisor so that multiple testcells could be tested concurrently an the same machine in an operating system environment. This turned out to have very low processor utilization and so the engineers started also using the "test" machines for other purposes. bldg 15 got one of the first 3033 engineering machines (outside of POK) for disk testing. partly because things were going very well ... they also managed to put together 16 3330 disk drives and 3830 controllers where the machine could be concurrently used for other purposes. this was during a period when there was heavy 3880 controller development and testing going on. at one pointer there was a "formal" product performance acceptance test for the 3880 done in STL using standard operating system testing. then bright and early one monday i got a call from the engineers in bldg 15 asking what i had done over the weekend to totally destroy there system thruput. I said I hadn't done anything ... and they claimed they hadn't done anything. So i had to start diagnosing what went one. It turns out that over the weekend, they had replaced the 3830 (for the string of 16 3330 drives) with a 3880 controller. The problem was that in the move from 3830 to 3880 they went from a ("fast") horizontal microcoded processor to a much slower vertical microcoded processor (with a separate data path). As a result, the 3880 had much slower command and funtion processing ... and initially failed the "formal" product performance acceptance test. The 3880 was then tweaked to present "early" interrupt to the channel (indicating operation complete) before the 3880 had finished all its operation. Then the 3880 could complete its operation in parallel with the operating system processing the interrupt and getting around to redriving i/o. This didn't bother the standard operating system formal performance acceptance tests. The problem was that I had significantly redone the I/O subsystem, not only to make it much more reliable and available than standard MVS ... but interrupt processing was dramatically faster than standard MVS ... and would get around to redriving i/o .... before the 3880 controller had finished its housekeeping. Hitting the 3880 controller while it was still busy doing something else ... then resulted in a whole bunch more 3880 controller overhead. The net was that the thruput of 3880 was significantly worse than 3830 controller in the same exact configuration. The whole net of this was that I claimed that I could come within a couple percent of the XA queued I/O interface thruput ... using standard 370 instruction implementation (w/o sacrificing reliability or availability) ... assuming that it was still same processor ... queued i/o was being performed by microcode on the same processor running 370 instruction microcode ... not offloaded to dedicated microprocessor (as I had defined in '75 as part of the 5-way smp project) aka initial Xa queued I/O architecture change was based on just redoing MVS i/o interrupt and redrive instructions in microcode, running on the same processor). Later 3090, had to add additional TCM for more channels needed in every 3090 system. Original 3090 thruput and manufacturing had been spec'ed on 3830 controller channel busy overhead per operation. The 3880 controller also significantly drove up channel busy overhead per operation, resulting in needing a lot more channels in order to achieve target 3090 system thruput. There was some rumbling about POK getting the corporation to debit the disk division for the increased 3090 manufacturing costs for each additional TCM. ---------------------------------------------------------------------- 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
