A couple of things: A CPU second is a constant. It has nothing to do with the hardware. It is the approximate number of seconds where a given CPU was observed to be doing work as opposed to being in a wait state. How much work is done -is- a variable that does depend on the hardware. You increase your service delivery by faster CPU's, more of them, reduced workload, or some combination thereof.
'Sub capacity' is a billing/pricing strategy and does not mean slower processors. Indeed, it is often a business justification for faster processors. With the 'sub capacity' strategy comes tools such that management can set some pretty firm limits on software costs. It is not and should not be confused with CoD. You may choose whichever is a best fit for your specific business situation. You can even choose combinations if you run more than one box. For example, 'sub capacity' allows for brief spikes in utilization without penalty. You are right in that the 'capacity' of modern boxes is no longer a constant. Indeed, depending on your strategies, it can and will vary moment to moment. With this variability, 'normalization' is difficult at best. I might propose that a meaningful measurement might be to calculate an average of the ratio of capacity used vs capacity available for each measurement interval. Again, a CPU second may not a good measurement of CPU capacity. IMHO, the best measure of latency is when service level objectives are missed. Perhaps the second best is counting the number of intervals when the box is running full out. You just can't push the utilization to 100% without latency. Interestingly enough, CPU seconds just might be a useful metric for this specific case. That is, if a CPU did not enter a wait state for x clock seconds, then it is safe to assume that there was latency for each of those x clock seconds. Latency would increase exponentially as x increases. Or so queuing theory would suggest. HTH and good luck -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Barbara Nitz Sent: Tuesday, July 05, 2011 6:23 AM To: IBM-MAIN@bama.ua.edu Subject: How many CPU seconds can I consume per 10minutes? Background: Traditionally, we have been reporting cpu usage for our box normalized to 100% using the TYPE70PR SMF records. Unfortunately, when the model of the box changes via CoD (or whatever it is called), you cannot even *see* that the capacity has become bigger. Using the total cpu seconds consumed, what you can see is that more cpu seconds were used in the same length interval, either because the number of processors increased or because the processor speed increased. So I have been thinking of doing the 'cpu usage per box' graphic using total cpu consumed in each interval. Which raises the question "what is the limit of cpu seconds per interval?" Because that is what I need to show management to show how much more we would have needed. We are running on a sub-capacity machine (and our new one will also be sub-capacity, meaning slower processors). So obviously I cannot use 60s*10*no.of.cps to determine the limit, since we will not achieve 600s cpu on one cp per 10minutes for general cps. I think. In addition, I wanted to avoid conversion to MSUs or MIPS (since I am always telling my management that those are meaningless). But for the new machine zPCR was done for our workload by IBM. In the comparison the actual MIPS of several z196 models were downgraded in their number of MIPS (to account for lpar overhead and workload mix, IBM calls it zPCR MIPS). Which seems to confirm my thinking above. So my question is a) if my thinking above is correct or flawed (and please set me straight if it is flawed). And b) how do I determine the maximum number of cpu seconds I can have in any 10-minute-interval at 100% load on the general cps? (I did search the archives, but did not really find anything that might be relevant.) Thanks for reading, Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
