Ron and Jenny Hawkins wrote: > Ted, > > It was actually cache that caused the rethink on VTOC and dataset > positioning, not volume size. First did this on a 3880-23 (SYSRES), but I'm > sure it was just as smart a move on 3880-13. > > For HDS it doesn't really matter if you put this stuff at the start, middle, > end or track 60000 - it is up to you (but I recommend the front). If this > stuff is active it usually lives in cache. > > If you have a volume where the VYTOC/VTOXIX/VVDS are busy enough to be a > real problem and cache algorithms are not favourable then you just use > FlashAcess* to turn it into a set of Solid State files - problem solved.
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. http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14 http://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14 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 assigned 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). http://www.garlic.com/~lynn/2006e.html#20 About TLB in lower-level caches http://www.garlic.com/~lynn/2006e.html#25 About TLB in lower-level caches 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: 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? 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). http://www.garlic.com/~lynn/subtopic.html#dasd 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). http://www.garlic.com/~lynn/93.html#12 managing large amounts of vm http://www.garlic.com/~lynn/93.html#13 managing large amounts of vm http://www.garlic.com/~lynn/94.html#9 talk to your I/O cache http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?" http://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File http://www.garlic.com/~lynn/2001l.html#55 mainframe question http://www.garlic.com/~lynn/2001n.html#78 Swap partition no bigger than 128MB????? http://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems? http://www.garlic.com/~lynn/2002b.html#16 hollow files in unix filesystems? http://www.garlic.com/~lynn/2002b.html#19 hollow files in unix filesystems? http://www.garlic.com/~lynn/2002b.html#20 index searching http://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates? http://www.garlic.com/~lynn/2002f.html#20 Blade architectures http://www.garlic.com/~lynn/2002f.html#26 Blade architectures http://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why? http://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible? http://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small clusters http://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters http://www.garlic.com/~lynn/2004h.html#19 fast check for binary zeroes in memory http://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer cylinders still faster than inner cylinders? http://www.garlic.com/~lynn/2005c.html#27 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ ---------------------------------------------------------------------- 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
