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] (Ted MacNEIL) writes: > Most of the time, I had already told them that there was an I/O > bottleneck, tape-drive contention, scheduling, etc. issue. But, they > told me to upgrade the processor, anyways. Yes, we usually needed the > processor, but the other issues would usually give us a better > improvement. starting in the mid-to-late 70s ... i was observing that systems were becoming more i/o bound ... and increasing real storage was more and more being used to compensate for i/o limitations. part of the issue was the work that i was doing on dynamic adaptive resource scheduling ... included some stuff to dynamicly adapt to resource bottlenecks. real storage, paging i/o and processor time was becoming less & less frequently primary bottleneck. along the way i had made the comment that relative system disk thruput technology had declined by an order of magnitude over a number of years. at some point this drew the attention of some execs in the disk division ... who asked their performance group to refute the statement. after a couple weeks, the group came back and said that i had somewhat understated the situation. part of the analysis was eventually reworked as disk thruput recommendations for a share presentation. old post with acknowledgement from b874 at share 63: http://www.garlic.com/~lynn/2006o.html#68 DASD Response Time (on antique 3390?) old post with summary from presentation b874 at share 63: http://www.garlic.com/~lynn/2002i.html#18 AS/400 and MVS - clarification please other post with reference to b874 http://www.garlic.com/~lynn/2006f.html#3 using 3390 mod-9s in the 80s there was increasing shift to using real storage to compensate for increasing disk i/o thruput limitations. an example is upswing of relational databases. the original relational/sql effort was done on vm370 platform at research http://www.garlic.com/~lynn/subtopic.html#systemr there was some discussions that went on with the ims people in stl (as well as consulting with them) vis-a-vis the difference between 60s dbms and relational dbms. the stl view-point was that relational implicit index doubled the physical disk space requirement and significantly increased the disk i/os for accesses (to process the index structure) ... compared to the direct record pointers (part of data infrastructure) then in common use. the relational position was that the implicit indexes, abstracted away directly exposing record pointers ... significantly reducing the manual maintenance in the care and feeding of dbms. the big upswing in amount of system real storage during the 80s allowed for relational index structure to be cached ... significantly reducing the i/o penalty. disk storage also became significantly cheaper starting to tip the balance between hardware/thruput costs (for relational) vis-a-vis skills & manual costs (for 60s dbms technologies). for other topic drift ... posts about getting to play disk engineer in disk engineering (bldg 14) and product test lab (bldg 15) http://www.garlic.com/~lynn/subtopic.html#disk past posts in this thread: http://www.garlic.com/~lynn/2008c.html#78 CPU time differences for the same job http://www.garlic.com/~lynn/2008c.html#80 Random thoughts http://www.garlic.com/~lynn/2008c.html#81 Random thoughts http://www.garlic.com/~lynn/2008c.html#82 CPU time differences for the same job http://www.garlic.com/~lynn/2008c.html#83 CPU time differences for the same job http://www.garlic.com/~lynn/2008c.html#84 CPU time differences for the same job ---------------------------------------------------------------------- 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
