Re: DASD Response Time (on antique 3390?)
re: http://www.garlic.com/~lynn/2006o.html#68 DASD Response Time (on antique 3390?) part of this is global cache/lru vis-a-vis local cache/lru. i had been doing global cache management nearly 40 years ago in cp67 ... at the time when at least some of the academic literature was focused on local lru and effectively partitioned cache operation. numerous past posts mentioning global lru stuff http://www.garlic.com/~lynn/subtopic.html#wsclock the detailed file i/o cache modeling mentioned in the ref. thread posting ... basically found that (all things otherwise being equal), for a given amount of aggregate electronic memory, a global, non-partitioned cache was more effective than any partitioning the same amount of electronic memory. earlier this week, in several hotchip presentations on multi-core designs, there were similar claims. L1 caches were effectively partitioned/local to a specific core. the scenario here was that latency issues negated the condition of all other things being equal. however, the larger L2 caches were non-partitioned, global, shared ... effectively the latency being equal between L2 and all cores. another counter example ... to all things otherwise being equal was numerous previous postings about cluster 4341 configurations compared to 3033. six clustered 4341s with 16mbytes each (96mbytes aggregate), six i/o channels each (36 channels aggregate) had higher aggregate mip rate than 3033 with 16 i/o channels and 16mbytes memory ... at about the same price. the disk i/o bottleneck and the limited real storage on the 3033 (to use as compensation for the disk i/o bottleneck) was one of the things that prompted the 32mbyte real storage hack offering for the 3033. even though standard 370 addressing (both real and virtual) was limited to 24bits (16mbytes). the 370 page table entry had 16bits, 12bit real (4k) page number (12bit virtual page * 12bit virtual page number yields 24bit virtual addressing), two flag bits, and two unused bits. the two unused bits were re-assigned so that they could be concatenated with the 12bit real page number to allow specification of up to 14bit (14bit*12bit=26bit or up to 64mbyte real addressing). instructions (both real and virtual) couldn't address more than 24bits ... but this hack allowed being able to utilize more than 16mbytes of real storage (for virtual pages belonging to multiple different address spaces). previous mentioning the clustered 4341 vis-a-vis 3033 and/or the 3033 32mbyte real storage hack: http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ??? http://www.garlic.com/~lynn/99.html#7 IBM S/360 http://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe? http://www.garlic.com/~lynn/2000d.html#7 4341 was Is a VAX a mainframe? http://www.garlic.com/~lynn/2000d.html#12 4341 was Is a VAX a mainframe? http://www.garlic.com/~lynn/2000d.html#82 all-out vs less aggressive designs (was: Re: 36 to 32 bit transition) http://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation? http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic) http://www.garlic.com/~lynn/2001j.html#3 YKYGOW... http://www.garlic.com/~lynn/2001l.html#32 mainframe question http://www.garlic.com/~lynn/2001m.html#15 departmental servers http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home http://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel? http://www.garlic.com/~lynn/2002i.html#22 CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2002i.html#23 CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033 http://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore http://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters http://www.garlic.com/~lynn/2004l.html#10 Complex Instructions http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor 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#57 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory? http://www.garlic.com/~lynn/2005.html#43 increasing addressable memory via paged memory? http://www.garlic.com/~lynn/2005f.html#4 System/360; Hardwired vs. Microcoded http://www.garlic.com/~lynn/2005n.html#11 Code density and performance? http://www.garlic.com/~lynn/2005n.html#29 Data communications over telegraph circuits
Re: DASD Response Time (on antique 3390?)
On Thu, 2006-08-24 at 13:27 -0600, Anne Lynn Wheeler wrote: ... basically found that (all things otherwise being equal), for a given amount of aggregate electronic memory, a global, non-partitioned cache was more effective than any partitioning the same amount of electronic memory. Everything we learnt by efforts such as the above has to be re-learnt today apparently. Even the cheapest PC has cached disk - then there are the decent controller cards. And Linux uses a dynamic (global) cache and disk buffer to try and alleviate I/O penalties. The mainline code also attempts to optimize the physical I/O - which can be of debatable benefit given the new(er) kit. At least (in Linux) you have the choice of I/O schedulers at boot if you are of a mind to tinker. Then there is the small matter of the swap (actually page) datasets. History repeating ... Shane ... -- 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
Re: DASD Response Time (on antique 3390?)
On Wed, 23 Aug 2006 14:27:07 -0500, David Day wrote: I'm developing some code on a Flex-es machine and would like to try to see how the code will work in a real environment. ...snippage... The Flex system has the ability to delay the I/O that it delivers to MVS. I would like to set these delay values to something that more resembles actual I/O response times. If someone can give me some values to plug in, I'd appreciate it. 3390's, with and without a caching controller. I know the values vary with cached controllers and hit ratios. I'm interested in the response time RMF reports when the data is found in the cache. Does anyone (outside of military, FAA, or the Smithsonian) have 3390 disk without cache these days? I know that I haven't seen one in probably 10 years. If so, do you have a parts supply still available or are the disks on the if it dies, it dies philosophy? -- Tom Schmidt Madison, WI -- 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
Re: DASD Response Time (on antique 3390?)
your absolutely right. I should have given my question more thought before asking. I've been out of touch with real world DP centers for a long time. Memory is so cheap and plentiful that it makes no sense to not use it to improve DASD times. --Dave Day - Original Message - From: Tom Schmidt [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Wednesday, August 23, 2006 2:37 PM Subject: Re: DASD Response Time (on antique 3390?) On Wed, 23 Aug 2006 14:27:07 -0500, David Day wrote: I'm developing some code on a Flex-es machine and would like to try to see how the code will work in a real environment. ...snippage... The Flex system has the ability to delay the I/O that it delivers to MVS. I would like to set these delay values to something that more resembles actual I/O response times. If someone can give me some values to plug in, I'd appreciate it. 3390's, with and without a caching controller. I know the values vary with cached controllers and hit ratios. I'm interested in the response time RMF reports when the data is found in the cache. Does anyone (outside of military, FAA, or the Smithsonian) have 3390 disk without cache these days? I know that I haven't seen one in probably 10 years. If so, do you have a parts supply still available or are the disks on the if it dies, it dies philosophy? -- Tom Schmidt Madison, WI -- 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 -- 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
Re: DASD Response Time (on antique 3390?)
On Wednesday, 08/23/2006 at 05:08 EST, David Day [EMAIL PROTECTED] wrote: your absolutely right. I should have given my question more thought before asking. I've been out of touch with real world DP centers for a long time. Memory is so cheap and plentiful that it makes no sense to not use it to improve DASD times. Never generalize. I always say! In virtual environments that overcommit real memory, blindly using host memory as a disk cache can actually *hurt* your response times since it puts more paging load on the system and actually decreases the ability of the hypervisors to manage throughput since the I/O buffers have to be locked in memory. On the mainframe, we have excellent control units with good caching capability. Let 'em do it. (This is one of the things z/VM uses expanded storage for: minidisk cache.) Alan Altmark z/VM Development IBM Endicott -- 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
