Performance and Capacity Planning
z995? Yup. IBM's next mainframe will have a name - like the others - beginning with a z. The 995 part is simply a count of the number of codenames it's had so far. Including TPTUTBKAGE. (You couldn't make it up.) -- Phil Payne +44 7833 654 800 -- 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: Performance and Capacity Planning
z995 ? -Original Message- Phil Payne snip That presentation is now public domain - if I can't find it on the GSE site I'll post it on mine. I have the same for the z990 and the z995 - and for something else. unsnip -- Phil Payne +44 7833 654 800 -- 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: Performance and Capacity Planning
... capacity (in MSU) makes that possible ... It may make it possible, but I hope you don't have anything bigger than a 16-way, or else you will be overcharged. Of course, any arbitrary number can make anything possible. [EMAIL PROTECTED] -- 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: Performance and Capacity Planning
And Phil will no doubt appreciate the free plug. His disclaimers generally make the best reading ... Shane ... - Original Message - Anyone want to discuss LSPR, MIPS, RMF and SMF ? I found a free mips msu chart at : http://www.isham-research.co.uk/mips_z990.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: Performance and Capacity Planning
On Fri, 3 Jun 2005 06:09:20 -0400, Paul Hanrahan [EMAIL PROTECTED] wrote: Shane, Walker wants me to pay for a chart. Gartner wants me to pay. If Phil made the charts available then I thank him. My boss didn't seem to think I had a need to know even though I was doing monthly MIPS reports so finding a free chart was very helpful. Glasshouse Systems' chart is also free; http://www.glasshousesystems.com/GH_2H2004_zSeries.pdf DC -- 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: Performance and Capacity Planning
Dave Cartwright says Glasshouse Systems' chart is also free; http://www.glasshousesystems.com/GH_2H2004_zSeries.pdf There are plenty of MIPS charts floating around the ozone both free and fee based. Cheryl Watson charges for access to her newsletter and the fruits of her research. That fee is chump change, so I don't begrudge Cheryl in the slightest. If she can recover a buck, more power to her. Phil gives his away and that's fair enough too. I am more bothered (as Ed Jaffe was) by the question of why anyone pays attention to MIPS numbers any more. There was quite a fuss a couple of SHARE's ago with underperforming z990s. Maybe they were and maybe they weren't but the real problem is that todays machines are wildly different beasts than the good old System/370 Model 158 that has been the reference standard for 1 MIP - AND - the software, the applications and workloads are also wildly different. We're comparing apples and fish. Who cares what the units are? BTW do y'all realize the 990 is really a NUMA machine? It makes a huge difference between accessing resources in the same book and another book. Expecting it to be otherwise is not entirely rational. Hence, some things can run like greased cheese while other things might struggle relative to your expectations. Those differences are only going to become more acute as the technology evolves. -- 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: Performance and Capacity Planning
For a fairly decent description, try looking at: http://lse.sourceforge.net/numa/faq/ Chris Blaicher -Original Message- From: Eric Bielefeld [mailto:[EMAIL PROTECTED] Sent: Friday, June 03, 2005 11:26 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Performance and Capacity Planning Chris, Two things. 1. What is a NUMA machine. How does being NUMA affect performance or MIPS values. 2. I still think that MIPS is a good measure of performance, if used within the same line of computers. If you compare the z/890, or z/990 models, MIPS gives a good relative value of what to expect. If you compare them to a 9672, it probably isn't as relevant. The fact the IBM, when announcing new hardware, usually prints MIPS in their charts says that it is still a valid number. I'm not saying it is best, or that there isn't problems with MIPS, but the MIPS numbers still make more sense to me than any other indicators. Eric Bielefeld PH Mining Equipment -- 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: Performance and Capacity Planning
Eric Bielefeld wrote: ... The fact the IBM, when announcing new hardware, usually prints MIPS in their charts says that it is still a valid number. Which charts? A web URL would be helpful. I'm not saying it is best, or that there isn't problems with MIPS, but the MIPS numbers still make more sense to me than any other indicators. MSU values are reported by the hardware. MIPS values aren't. That single difference makes MIPS inherently less useful than MSU -- all other things being equal. See: http://bama.ua.edu/cgi-bin/wa?A2=ind0411L=ibm-mainP=R35634 -- - | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | - -- 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: Performance and Capacity Planning
... MSU values are reported by the hardware. MIPS values aren't. That single difference makes MIPS inherently less useful than MSU ... Since IBM changed the billing algorithms for MSU, that makes MIPS les useful than a useless number for MSU. Just because the hardware reports it doesn't make it valid. SU/sec is a single number that MSU is based on, derived by LSPR. But, LSPR is very suspect now. So are MSU's since marketting got involved in a technical description. Isn't it amazing that senior execs are spending millions on a number that is not much more than a WAG? [EMAIL PROTECTED] -- 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: Performance and Capacity Planning
Ted MacNEIL wrote: ... MSU values are reported by the hardware. MIPS values aren't. That single difference makes MIPS inherently less useful than MSU ... Since IBM changed the billing algorithms for MSU, that makes MIPS les useful than a useless number for MSU. Not useless at all! Suppose you have a licensing agreement that limits the capacity of the hardware environments on which a software product is licensed to run. If that agreement is written using MSU terminology, then a (fairly) simple query of the hardware lets both the software product and the customer know if the environment is compliant. Customers generally prefer software that can help them ensure the terms and conditions of their license agreements are being met. Such software helps customers avoid liability and breach of contract issues. For capacity-based licenses, hardware reporting of serial numbers, LPAR names, and capacity (in MSU) makes that possible! My point was simply that no similar capability exists for MIPS, making MIPS inherently less useful than MSU -- all other things being equal. The validity of that statement should be obvious. It's hardly arguable. Just because the hardware reports it doesn't make it valid. It's valid for the intended purpose so long as the number being reported matches the published number. If you don't like the published number for certain models, take it up with IBM. That's completely tangential to my point. -- - | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | - -- 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: Performance and Capacity Planning
Comments interspersed. On Fri, 3 Jun 2005 11:04:51 -0700, Edward E. Jaffe [EMAIL PROTECTED] wrote: Eric Bielefeld wrote: ... The fact the IBM, when announcing new hardware, usually prints MIPS in their charts says that it is still a valid number. Which charts? A web URL would be helpful. The charts I am referring to were handed out in Nov. 2004 at an IBM Roadshow meeting. The presentation is titled zSeries z900 and z990 Update 2004 and was givin by Bob Neidig of IBM. If you really wonder, I could fax you 1 or 2, but the presentation is filled with MIPS. I doubt if this was ever put on a web page. I'm not saying it is best, or that there isn't problems with MIPS, but the MIPS numbers still make more sense to me than any other indicators. MSU values are reported by the hardware. MIPS values aren't. That single difference makes MIPS inherently less useful than MSU -- all other things being equal. See: http://bama.ua.edu/cgi-bin/wa?A2=ind0411L=ibm-mainP=R35634 I also qualified the use of MIPS in my original comment by saying that comparisons within a line of computers, such as z/890 z/990. Comparing a 1 processor z/990 to a 30 processor z/990 should give a good comparison if you are using MIPS. Obviously, your particular workload may give somewhat different numbers, but then it probably would with MSUs also. MIPS have been around a lot longer than MSUs. They are more familiar to me, which is why I like them. I still remember my 158 with an attached processor. The main CPU alone gave 1 MIP, and with the AP, it was 1.8 MIPS. Back in 1980, that was a good sized machine. Eric Bielefeld -- - | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | - -- 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: Performance and Capacity Planning
Eric said; I also qualified the use of MIPS in my original comment by saying that comparisons within a line of computers, such as z/890 z/990. Comparing a 1 processor z/990 to a 30 processor z/990 should give a good comparison if you are using MIPS. Obviously, your particular workload may give somewhat different numbers, but then it probably would with MSUs also. This is really where the standard way of thinking about these things just falls apart. There are multiple levels of virtualization within these systems. It is meaningless to talk about the capacity of the entire processor (CEC) when the processor is just a container for one or more LPARS. Moreover, the mix of resources and workloads is both unpredictable and irreproducable. If you study the LSPR information (ignoring for a moment whether you believe it) you see a wide variety of throughput results depending on configuration and workload mix. It is completely hopeless to think of that in terms of a single number called MIPS even if that number gives you some comfort. MIPS have been around a lot longer than MSUs. They are more familiar to me, which is why I like them. I still remember my 158 with an attached processor. The main CPU alone gave 1 MIP, and with the AP, it was 1.8 MIPS. Back in 1980, that was a good sized machine. And today it would be less than a rounding error. That's the point. The way that we as a community thought about these systems back then is just not relevant or valid any more. MSU numbers are at least a shot at adjusting the scale of reference, but ultimately there is no substitute for measuring your own throughput with your own mix. -- 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: Performance and Capacity Planning
On 3 Jun 2005 09:45:31 -0700, [EMAIL PROTECTED] (Blaicher, Chris) wrote: For a fairly decent description, try looking at: http://lse.sourceforge.net/numa/faq/ That was a very helpful link; thanks for posting it! I've never dived this deeply into hardware architecture; it's fascinating. The z990 Reference Guide contains the statement: All books are interconnected with a super-fast bi-directional redundant ring structure which allows the system to be operated and controlled by PR/SM operating in LPAR mode as a symmetrical, memory coherent, multiprocessor. After thinking about this passage, I have a couple of questions. When a z990 contains more than one book, each book's local memory obviously represents only a part of the system's total address space. Each book needs some sort of address decode mechanism to determine whether a particular address references memory local to the book or on another book in the system. How is the base address of each book's memory assigned? (Book A's local memory represents the first 16GiB, Book B the next 32GiB and Book D the last 16GiB, for a total system memory of 64GiB, for example.) Is this allocation done through some sort of configuration process, or does the hardware handle the assignments? When defining LPARs, it seems that there may be an advantage to having an LPAR's address space backed by a single book's memory. For example, defining an LPAR that used one processor from Book A, but 8GiB of memory from Book A and 8GiB from Book B wouldn't seem as efficient as defining the same LPAR using all 16GiB from Book A. Forgive me if these questions seem a little basic, but I've never configured zSeries hardware, especially on large systems that might contain multiple books. Seems like system configuration on a large box could get quite subtle! Eric -- Eric Chevalier E-mail: [EMAIL PROTECTED] Web: www.tulsagrammer.com Is that call really worth your child's life? HANG UP AND DRIVE! -- 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: Performance and Capacity Planning
Howard Brazee wrote: On 3-Jun-2005, [EMAIL PROTECTED] (Edward E. Jaffe) wrote: My point was simply that no similar capability exists for MIPS, making MIPS inherently less useful than MSU -- all other things being equal. The validity of that statement should be obvious. It's hardly arguable. The proviso all other things being equal is very useful when one is pointing to a feature and implying that that feature is sufficient to make the whole argument valid. MIPS and MSU are used interchangeably for capacity-based contract licensing purposes. In that sense they *are* equal. Whether you agree with the analysts ratings or not is irrelevant. You can complain to IBM about MSUs. You can complain to Gartner, Watson Walker, Isham or any other analyst about MIPS. Again: THE HARDWARE USES AND REPORTS MSU -- NOT MIPS! That makes MSU *vastly* superior for the purpose described. -- - | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | - -- 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: Performance and Capacity Planning
... That makes MSU *vastly* superior for the purpose described. ... How can something meaningless be superior to other meaningless measures? [EMAIL PROTECTED] -- 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: Performance and Capacity Planning
Customers prefer software that keeps it's nose out of make/model/CPU. Customers prefer software that doesn't require a zap or execution of some rare breed of vendor utility to update license load modules. Customers prefer to keep track of TCs and the software inventory and deal with license issues in the mail not during a hardware upgrade. Do I have to ZAP z/OS, DB2, MQSeries, or CICS when I upgrade my hardware or go to a DR site? NO! Do I have to pay IBM following mutually entered TCs? YES! ISVs forced date, make/model/serial# checking on customers. I guess very few customers asked for it and none I personally know of. I don't know of any vendor other than IBM that just produces SMF records for subsequent billing and validation. Reporting is required to help them ensure the... enforcement is not but you won't find many vendors that volunteer non-CPU specific license codes until hard fought negotiations. Every ISV I know introduced serial# checks to prevent fraud or facilitate limited time trials. None I know can claim they did it because customers clamored for it. My .02 Thanks, Sam -Original Message- Customers generally prefer software that can help them ensure the terms and conditions of their license agreements are being met. Such software helps customers avoid liability and breach of contract issues. For capacity-based licenses, hardware reporting of serial numbers, LPAR names, and capacity (in MSU) makes that possible! This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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: Performance and Capacity Planning
Knutson, Sam wrote: Customers prefer software that keeps it's nose out of make/model/CPU. Customers prefer software that doesn't require a zap or execution of some rare breed of vendor utility to update license load modules. Customers prefer to keep track of TCs and the software inventory and deal with license issues in the mail not during a hardware upgrade... [snip] Not sure what this rant has to do with the subject at hand. Are you saying you believe MIPS measure to be in some way superior to MSUs??? WRT to customer requests yada, yada... We were asked by a representatives of the 2nd largest corporation _in the world_ to ensure our products produced warnings when being executed in an unlicensed environment. From the way it was presented, my impression was that we were not the only ISV targeted with this request. -- - | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | - -- 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
