using 3390 mod9s 3187

Ron and Jenny Hawkins

the other view is that caches were required because careful positioning was no longer sufficient.

starting with os-360 release 11 ... i began very careful stage2 sysgens to place datasets and order pds members to optimize disk arm motion. i would take the stage1 punched output (stage2) deck. i would reorganize the stage2 cards to result in carefully places system data. for a lot of the university workload, i got nearly three times the system thruput (compared to an out-of-the-box sysgen).

a problem was that thruput would degrade nearly in half over six month period as APARs were applied ... and careful PDS member ordering was disturbed (and i would have to rebuild systems).

i gave a number of presentations at share about the effort applied to both release 11 and 14 sysgens ... pointing out that if i could place the vtoc in the middle of the volume ... then i could order high activity system data on both sides of the vtoc (which was one of the highest activity system areas on disk). the next release was combined "15-16" and contained support for specifying vtoc cylinder location (able to place vtoc in the middle of the volume and then carefully order all the rest of the system data).

during that period i also rewrote much of the cp67 paging system, dynamic page allocation and disk i-o (including implementing ordered seek queuing).

following is post of part of presentation i gave at fall '68 share meeting in boston on both some of the os mft-14 work and cp67 work.

much, much later there was a project that did extensive gathering of real-live disk data useage ... it was implemented in vm370 kernel ... but was used to gather data from not only cms interative workloads ... but also from heavy production mvs systems (running in virtual machines). the gathered data was heavily analyzed including a detailed electronic cache model that looked at various infrastructure trade-offs ... like comparing ddevice, controller, channel, and system based caching strategies.

i had also done a report that claimed that disk relative system thruput had declined by a factor of ten over the years (i.e. systems had gotten 50 times faster ... but disk had only gotten 5 times faster). initially the disk division was upset and buttigned their modeling-performance group to refute the observation. however, after a couple months they came back with a report that effectively said that i had slightly understated the problem. this was turned around and the disk division used it for presentations at user group meetings about disk considerations for optimal system thruput. recent post mentioning the disk access cache modeling work (along with discussing a bunch of paging modeling work).

one of the strategies was to leverage the drastic increase in the amount of electronic memories for procedures to compensate for the trend in decreasing disk relative system performance (analogous to use of cpu caches to compensate for electronic memory speeds not keeping up with the increase in cpu speeds). misc. past posts mentioning the observations about declining disk relative system performance: out the Door other irrelevant concepts to Today's Micros? past?) that ran as slow as today's supercomputers? Disk? rates?

not too long after that, the disk division introduced the 3880-11 and 3880-13 disk caches. these were only 8mbytes ... so didn't make a lot of sense ... it you were running any sort of paging-caching mechanism based on system storage (typical 3081 configuration had 32mbytes ... so system storage tended to be a superset of what was in the controller cache. if it hadn't yet been brought into system memory, then it likely wasn't also in controller cache and would have to be fetched off (real) disk ... at which time it populated both the disk cache and system memory (i've done a number of posts about dynamically switching from "duplicate" and "no duplicate" caching strategies.

the specific thing that showed up in the 3880-13 marketing literature was showing that 3880-13 8mbyte cache obtained a 90precent hit rate in a large system heavy load environment. How, you might ask? The scenario was sequential single record read of a file formated with 10 4k records per 3880 track. The read of the first record on the track would be a miss and automatically transfer the whole track to the 3880-13 (full-track) cache. The next 9 sequential reads would be for records fetched with the record read on the track .. which would be in the cache. one might have been tempted to specify full-track blocking ... in which case the 3880-13 strategy would have gone from 90percent hit rate to zero percent hit rate.

3880-21 and 3880-23 increased the controller cache sizes from 8mbytes to 32mbytes (offering slightly improved chance ... that if you had a system using its own system level caching strategy ... that not every piece of data in the controller cache was simultaneously in main system memory.

by the late 70s, you were starting to see more and more systems heavily leveraging main processor store as caches to compensate for lagging improvements in disk thruput ... for any and all arbitrary system data. one might be tempted to observe that it would be a dificiency in MVS organization that it couldn't use system memory to cache one of its highest referenced disk data areas ... namely VTOCs ... and would have to wait until the availability of controller caches to mitigate system thruput problems with respect to VTOCs.

another issue is that in the mid-60s there was a trade-off of (disk) i-o thruput and real storage. real storage was severely limited ... and many file system designs from the era would cache very limited amounts of heavily used system data. 360s used CKD search strategies to basically trade-off the relatively abundant-excess i-o capacity against the extremely limited real storage. However, by the late 70s the resource characteristics were reversing the trade-off ... however mvs was still using ckd multi-track searches for vtoc and pds directories (type of information that by this time, other systems were regularly caching in real storage). lots of past postings about being brought into customer shops to look at severe (multi-)system thruput problems being cause by multi-track searches (primarily with VTOCs and PDS directories).

lots of past posts discussing "dup" and "no-dup" (duplicate and no-duplicate) cache strategies (where you have multi-level caching where different levels are similar in aggregate size). 128MB????? rates? possible? for small clusters for small clusters for small clusters in memory outer cylinders still faster than inner cylinders?

--