Tom, All this verification testing is great, and I know that there are people that have done it. I don't know where you've worked over the years, but I've worked for banks. Typically banks don't let their systems programmers "play" with the systems like that, or at least the ones I've been in don't. Especially in these days of ATMs and Online Banking and 24 by 7. Having a kind of scientific mindset and background (EE undergraduate degree) I'd love to do this type of testing. If I'd been able to do that over the years I'd probably know a lot more than I do now. However, I guess I'll just have to rely on this board and others like it and research papers to get my technical information.
Tom Kelman Commerce Bank of Kansas City (816) 760-7632 > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Tom Marchant > Sent: Monday, February 04, 2008 6:24 PM > To: [email protected] > Subject: Re: CPU time differences for the same job > > On Mon, 4 Feb 2008 15:54:23 -0600, Kelman, Tom wrote: > > >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. > > Ahh.... Charge back. That's a difficult subject. Still, you need not > necessarily throw much of it out. The effects that I was describing might > be > difficult to show. > > If I were to try to demonstrate these effects on a z9 BC, here's ow I'd > set up > a test. First, I'd need an LPAR with an extremely low weight. Perhaps a > weight of 1 with the other LPARs adding up to a few hundred. My test LPAR > would get very poor service indeed. I'd load down my other LPARs with > programs that would not do any I/O and that would reference a *lot* of > storage. The BC has 256K of data cache and 256K of instruction cache on > each PU. In addition, there is 40 MB of Level 2 cache on the MCM. I'd > have > each of these programs reference enough memory to (probably) use every > line > in secondary cache, perhaps by dividing a 40 MB area into two 20 MB > sections > and moving data back and forth between them. I'd run several of these on > my > high weight LPARs, at least as many as there were LPs on each partition. > I'd > run a few on the low weight partition, too, but there I'd make sure that > they > had a lower priority than my test program. The test program would > reference > a byte of memory at 64 byte intervals over a range of perhaps 64K. Then > it > would issue a STIMER WAIT. A few seconds should be sufficient. During > the > time that it was waiting, its cache would tend to all be stolen and the > next > time it would have to go to main store again. It might take a few > thousand > iterations to use enough CPU to be measurable. Repeat the test on a > lightly > loaded LPAR with little memory contention from other LPARs and I'm sure it > would use considerably less CPU time. > > -- > Tom Marchant > > ---------------------------------------------------------------------- > 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
