Tom, What you and others have said here has really got me thinking. It's been about 20 years since I was really an MVS System Programmer getting into the bowels of the operating system. I've been a performance tuner and now a capacity planner for many years. However, what has been said here about the variability of CPU time seems to through all my ideas about capacity planning and charge back algorithms out the window. If the CPU usage is that variable how can one relate the usage of CPU within a given application back to business units, which I'm constantly trying to do? Also, how does one change equitable for CPU utilization if it can vary so much just because there might be a cache miss caused by an interrupt that is not necessarily the fault of the executing program? The shop I'm in now is fairly small with a z9BC of 1004 MIPS and just 3 LPARs. We aren't SYSplexed (no CF) and there isn't even a shared JES spool, but there is shared DASD. Maybe it's the relative simplicity of the shop, but I've found CPU times to be pretty consistent.
Tom Kelman Commerce Bank of Kansas City (816) 760-7632 > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Tom Harper > Sent: Monday, February 04, 2008 2:34 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: CPU time differences for the same job > > Tom, > > Yes, you are missing something here. Others have mentioned it, but I > will mention it again: Modern processors make extensive use of > multi-level cache. When not interrupted, the cache does a great job of > improving the performance of the processor by pre-fetching instructions > and data post-storing results. The key words here are "not interrupted". > Interruptions can occur for normal interrupts in this z/OS system, such > as I/O completing, etc., and can occur for other LPARs when the > hyper-visor interrupts the processor to dispatch another LPAR. Dedicated > LPARs can remove those types of interrupts. But this is exactly the > point: the job mix on this LPAR and other processors can and do affect > CPU times significantly. > > Another fact not well understood is the magnitude of performance > degradation when a cache miss occurs. Bob Rogers at the last SHARE > mentioned that while cache misses in first and second-level caches were > not too bad, cache misses that resulted in actual references to memory > could be as much as 600 times slower. His comment: It's almost like > doing an I/O to reference main storage compared to getting a hit in > first-level cache. > > You may want to read up on this in the IBM systems journal: > > http://www.research.ibm.com/journal/rd51-12.html > > Tom Harper > IMS Utilities Development Team > Neon Enterprise Software > Sugar Land, TX > > Tom Kelman wrote: > > Am I missing something here? Miklos is asking about the difference in > CPU time between two runs of the same job step. I would think that if > the same program was processing the same data in the same way the CPU > time should be close to consistent. Maybe not exactly the same but > there shouldn't be "several times another". Now the elapsed time could > vary widely depending on the contentions that Tom has mentioned above. > > > Tom Kelman > Commerce Bank of Kansas City > (816) 760-7632 > > ---------------------------------------------------------------------- > 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 ***************************************************************************** If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. ***************************************************************************** ---------------------------------------------------------------------- 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
