Anne & Lynn Wheeler wrote: > there was some mvs kernel performance assist microcode done for 3033 ... > somewhat analogous to vm ecps originally done on 148 ... but it was > difficult to actually demonstrate much performance improvement because > 370 instructions already running at or close to hardware speed.
3033 had several issues ... cluster of six 4341s were about the price of a 3033, had higher aggregate mip rate, aggregate of 96mbytes of real memory and aggregate of 36 channels. the 16mbyte real storage constraint on 370 ... was possibly one of the reasons for the 32mbyte real storage hack for 3033. it is still 370 16mbyte addressing ... but the 370 page table had 16bits ... 12bits to address up to 4096 4k pages (16mbytes), an invalid bit, a software use bit, and two undefined bits. the 3033 hack scavenged one of the two undefined bits to provide 13bits to address up to 8192 4k pages (32mbytes real). this allowed virtual memory pages to reside above the 16mbyte line ... even tho there was still only 24bit (virtual and real) addressing. there was then the kernel hack to move virtual page from above the 16mbyte line to below the line when operations needed to be performned on it. part of this was starting in the mid-70s ... typical systems were starting to shift from processor/memory constrained to i/o constraied. as a result, real storage was starting to be used more and more to mitigate the i/o constraint. part of the problem was the trade-off decision for os/360 using multi-track search in the mid-60s. the issue was that they could trade-off the excess i/o capacity against having indexes resident in constrained real memory. http://www.garlic.com/~lynn/subtopic.html#dasd by the late 70s there was numerous situations where the multi-track search was severely blowing what limited i/o capacity there was. a big contrast was that vm, cms, cms filesystem, etc had always used logical fba ... even when dealing with ckd dasd. sjr/bldg28 had especially extreme situations highlighting the problem ... sjs/bldg28 was where original relational/sql was developed on vm http://www.garlic.com/~lynn/subtopic.html#systemr for a time after the sjr 370/195/mvt system had been replaced ... there was a mvs/168 running in shared dasd configuration with vm/158. because of the severity of mvs multi-track search had on normal cms performance ... there was s standing rule that mvs packs would never be mounted on vm drives/controllers (multi-track search busied the channel, controller, and drive). one day, an operator mistakenly mounted a mvs 3330 pack on a vm drive/controller. within five minutes, cms users were phone the computer room complaining about extremely degraded response time degradation (note that TSO users never learned what good response was ... because TSO never operated w/o the underlying mvs operating system). there was a demand that the mvs pack be immediately moved to a non-vm drive. the mvs operator's declined. so the vm group mounted a specially tuned vs1 (that ran under vm) pack on a "mvs" drive and started up a specially constructed mutli-track search application. This had the effect of significantly slowing down the mvs system (vs1 running under vm on 158 vis-a-vis mvs running on 168). the mvs operators immediately moved the mvs 3330 pack off the vm drive/controller to a mvs drive and promised never to make that mistake again. a few past post mentioning the 4341/3033 rivalry issue (there was even an internal politic incident where 3033 group attempted to have the allocation of a critical 4341 component cut in half). http://www.garlic.com/~lynn/94.html#9 talk to your I/O cache http://www.garlic.com/~lynn/2001m.html#15 departmental servers http://www.garlic.com/~lynn/2004n.html#14 360 longevity, was RISCs too close to hardware? http://www.garlic.com/~lynn/2004n.html#50 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2004o.html#1 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design http://www.garlic.com/~lynn/2005p.html#19 address space http://www.garlic.com/~lynn/2005q.html#30 HASP/ASP JES/JES2/JES3 at one point, i produced a paper claiming that the relative system performance of disk had declined by a factor of 10 times over a period of 10-15 years (contributing to the use of excess real storage as mitigation for i/o constraint). the disk division got upset and assigned their performance group to refute the statement. after several weeks, they came back and said that i had slightly understated the issue. this eventually turned into a user group presentation by the disk division about how to optimize disk performance. the issue was that while disk performance had improved over the period .. it had improved less than performance of other system components ... leading to a decline in relative system performance for disk. misc. past posts on the subject: http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros? http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?) http://www.garlic.com/~lynn/98.html#46 The god old days(???) http://www.garlic.com/~lynn/99.html#4 IBM S/360 http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine? http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers? http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts) http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts) http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk? http://www.garlic.com/~lynn/2002.html#5 index searching http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching) http://www.garlic.com/~lynn/2002b.html#20 index searching http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates? http://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates? http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad ---------------------------------------------------------------------- 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
