The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
rfocht...@ync.net (Rick Fochtman) writes: > I wouldn't mind looking back at the "good old days", but only for > hysterical purposes. SIO/TIO/HIO are NOT areas I would care to revisit > for any productive purpose. :-) part of the redo of sio/tio/hio for xa (aka "811" for the nov78 date on the documents) was the enormous pathlengths in mvs ... being able to redrive queued i/o after completion of previous i/o. this showed up when i redid i/o supervisor for disk engineering labs. the disk engineering labs had tried doing development work under mvs ... but found that it was a 15min mean-time-to-failure ... even with single testcell. i redid i/o supervisor to never fail ... so that multiple testcells (disk development) could be exercised concurrently ... happen to mention the MVS 15min mtbf in purely internal report which brought down the wrath of the mvs organization on me (when I 1st took the call, i thot it was going to be about helping fix all the problems, but it was one of those calls getting told that I wasn't allowed to even mention such things in purely internal discussions). in any case, i got a call one monday morning asking what did i do to the 3033 system in the disk product test lab (bldg. 15) over the weekend ... that their performance went all to pieces. turns out i did nothing ... but they had replaced a 3830 controller (for 16 3330 drives) with brandnew 3880 controller over the weekend. diagnosing the problem turns out that the increased pathlength in the 3880 was so long ... that the 3880 (in order to meet performance specs) was presenting operation finished interrupt slightly early (before everything was completely clean up). My redrive pathlength was then so short ... that I was hitting the 3880 controller with the next queued request ... while it was still busy finishing cleaning up the previous operation. it was then forced to present CC=1, SM+BUSY (controller busy) to the SIO ... and then later present CUE interrupt (and the system had to requeue the operation and wait for the CUE). This drove up system overhead and reduced overall system thruput (by enormous amount ... compared to 3830 which I was running at very high rate). all of this was because I had been able to move the (stand-alone) disk testing in bldgs. 14 & 15 ... into operating system environment ... and since the testing only accounted for 1-2% cpu utilization ... they then started also using the machines for lots of other stuff. misc. past posts getting to play disk engineer in bldgs. 14&15 http://www.garlic.com/~lynn/subtopic.html#disk the 3880 had already passed its performance/thruput acceptance tests when this occured ... but fortunately it was still 6months before first-customer-ship ... so there was time to do additional fiddling in the 3880 controller. the other issue with the SIO/TIO/HIO and asynchronous interrupt paradigm ... besides wanting to quickly being able to do device redrive as quickly as possible (after completion of previous operation) was the havoc that asynchronous interrupts had on cache hit ratios (high interrupt rates could cut some cache hit rates significantly ... swithing back and forth between interrupt processing and application programming). I was also providing highly specialized systems for HONE (internal vm370 online system provided world-wide sales & marketing support). Large percentage of the applications were implemented in (cms) APL and as result were fairly processor hungry (in addition to doing lots of I/O). At one point they had opportunity to upgrade their loosely-coupled (single-system image) 370 operation to APs (multiprocessor configuration with 2nd processor that didn't have any channels). Normal 370 multiprocessor slowed the processor cycle by 10% for part of the (multiprocessor) cross-cache interactions. So a two-processor 370 ... started out as 1.8 times that of a single processor (multiprocessor software overhead could cut actual thruput to 1.3-1.5 times that of single processor). misc. past posts mentioning multiprocessor support http://www.garlic.com/~lynn/subtopic.html#smp For the AP multiprocessor support, I did some slight of hand ... and was getting better than twice the thruput of single processor ... because of significantly improved cache hit ratio of the processor w/o channels ... which way more than compensated for reduction of cache hit ratio of the other processor attempting to do twice as much I/O on single set of channels. misc. past posts mentioning online world-wide marketing & sales support http://www.garlic.com/~lynn/subtopic.html#hone Jan75 ... company was starting to deal with future system being failure ... and 370 wasn't going to be killed off http://www.garlic.com/~lynn/submain.html#futuresys I had continued to do 360/370 stuff all during the future system period ... I was caustic of their ability to pull stuff off and didn't drawn into their fantasy land ... and was being asked if I could help quickly get stuff back into the 370 product pipeline. Anyway, jan75, I got asked if I could do something with 5-way 370-based multiprocessor that had significant microprogramming stuff. I defined a queued interface for i/o (a little like the later xa-stuff) ... as well as a queued interface for multiprocessing task dispatching (a little like the later intel i432). the 5-way got terminated before even being announced ... some past posts http://www.garlic.com/~lynn/submisc.html#bounce the other way of looking at it was that it evolved into a 16-way 370 effort in its place ... which was even getting even better uptake around the company ... until somebody let slip to the head of POK that it would probably be decades before the favorite son operating system was able to support 16-way (then people got invited not to appear in POK again). -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
