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] (Anne & Lynn Wheeler) writes: > also, customers were finding that a vm/4341 cluster was cheaper than > 3033, higher aggregate mip rate, much larger aggregate storage, and > higher aggregate i/o capacity. There is folklore, that because of the > above ... at one point, POK directed Fishkill to cut the Endicott > allocation in half for a critical component needed for 4341 > manufacturing. > > One of the things that was happening by the mid-70s ... as processing > power was increasing ... disk thruput improvements weren't keeping pace > with processor speed improvements. as a result, systems were having to > rely more & more on larger & larger electronic storage ... to compensate > for the growing disk i/o bottleneck. 370s were stuck with 24bit > addressing and 16mbyte virtual and real storage ... which resulted in > significant constrained operation for many 3033s. re: http://www.garlic.com/~lynn/2010b.html#87 "The Naked Mainframe" (Forbes Security Article) http://www.garlic.com/~lynn/2010b.html#88 "The Naked Mainframe" (Forbes Security Article) http://www.garlic.com/~lynn/2010b.html#96 "The Naked Mainframe" (Forbes Security Article) recent post also mentioning vm/4341 cluster support http://www.garlic.com/~lynn/2010b.html#90 Happy DEC-10 Day and various vm/4341 cluster-wide operations going from small subsecond elapsed time to 30secs (or more) when forced to migrate to SNA for customer release. i had done dynamic adaptive resource management and something I called "scheduling to the bottleneck" as undergraduate in the 60s ... so was sensitized to being constantly on the lookout for changing bottleneck conditions. as a result, it wasn't unusual to find by the mid-70s, bottleneck was shifting to disk i/o ... and real storage was more and more being leveraged to compensate for the disk i/o bottleneck. by the early 80s, I had made statements about relative system disk thruput had declined by order of magnitude over period of years ... old post with comparison from the early 80 period: http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door i.e. the growth in cms users from cp67 on 360/67 to vm370 on 3081 should have been from 80 to something like 4000 ... instead of typically 300 (the ratio of 80:300 is more like change in disk thruput). disk division executives tasked their performance group to refute the statement ... but after a few weeks they came back and said that I had slightly understated the problem. the spin on the analysis was then changed to be recommendations on disk configuration to maximize system thruput ... and turned into share presentation (B874 @ SHARE 63, 8/18/84). some past references http://www.garlic.com/~lynn/2002i.html#18 AS/400 and MVS - clarification please http://www.garlic.com/~lynn/2002i.html#46 AS/400 and MVS - clarification please http://www.garlic.com/~lynn/2006f.html#3 using 3390 mod-9s http://www.garlic.com/~lynn/2006o.html#68 DASD Response Time (on antique 3390?) http://www.garlic.com/~lynn/2007s.html#5 Poster of computer hardware events? http://www.garlic.com/~lynn/2007s.html#9 Poster of computer hardware events? http://www.garlic.com/~lynn/2008c.html#88 CPU time differences for the same job http://www.garlic.com/~lynn/2009g.html#71 308x Processors - was "Mainframe articles" http://www.garlic.com/~lynn/2009i.html#7 My Vintage Dream PC http://www.garlic.com/~lynn/2009k.html#34 A Complete History Of Mainframe Computing http://www.garlic.com/~lynn/2009k.html#52 Hercules; more information requested http://www.garlic.com/~lynn/2009l.html#67 ACP, One of the Oldest Open Source Apps in the period between 3330/3350 and 3380 there was also software technologies about disk thruput ... basically analysing traces of disk record accesses ... and generating profiles for re-allocation for better arm balance and concurrent operation. One such application was then modified for specifying allocation for moving from 3330/3350 to 3380s. Sort of guideline was that 3380s had to be limited to 80% allocation in order to avoid degrading thruput compared to same data spread across 3330/3350 configuration (i.e. 3380 byte capacity increased by much larger factor then 3380 performance increase). another disk activity "trace" technology was extremely lightweight, originally used as part of electronic cache modeling. one finding was that given fixed amount of electornic cache ... using it for a single large system cache was better than dividing/partitioning it into channel, controller, and/or disk specific caches. Some work was then done on the lightweight activity trace regarding incorporating into standard system allocation ... for choosing optimal distribution of data (of course lots of that has now all been moved to complex disk subsystems). misc. past posts: http://www.garlic.com/~lynn/99.html#104 Fixed Head Drive (Was: Re:Power distribution (Was: Re: A primeval C compiler) http://www.garlic.com/~lynn/2000c.html#19 Hard disks, one year ago today http://www.garlic.com/~lynn/2001b.html#61 Disks size growing while disk count shrinking = bad performance http://www.garlic.com/~lynn/2001n.html#1 More newbie stop the war here! http://www.garlic.com/~lynn/2002c.html#53 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?) http://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2004o.html#8 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2004q.html#76 Athlon cache question http://www.garlic.com/~lynn/2004q.html#79 Athlon cache question http://www.garlic.com/~lynn/2005.html#4 Athlon cache question http://www.garlic.com/~lynn/2005s.html#45 winscape? http://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s http://www.garlic.com/~lynn/2006f.html#0 using 3390 mod-9s http://www.garlic.com/~lynn/2006i.html#27 Really BIG disk platters? http://www.garlic.com/~lynn/2006n.html#33 CRAM, DataCell, and 3850 http://www.garlic.com/~lynn/2006r.html#12 Trying to design low level hard disk manipulation program http://www.garlic.com/~lynn/2006y.html#35 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2007s.html#5 Poster of computer hardware events? -- 40+yrs virtualization experience (since Jan68), 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
