OK- I'll try it again. First there is the issue of Capacity. When you add specialty engines to an LPAR, the LPAR's capacity acts almost like the n-way increase. So, if you have a 10-way, and add 2 zIIPs and 2 zAAPs, that LPAR now acts almost like a 14-way. That decrease your capacity by about 7%. But if you are not running your systems or footprint constantly at 100%, it may not be an issue. With today's z10s, you are best served for capacity and performance with about a 20-30% white space.
Now, for performance, the overhead to switch from one processor to another is about 2-11%. 2% if you switch to a processor in the same core, 11% if it is another book. The processor cycles to move instructions and data in the Level 1, 1.5, and 2 caches is actually slower than on a z9. On z10s, the busier the engines are, the less throughput you are likely to get. Search IBM's WSC for a white paper by Gary King on running fast processors at 100% busy. But again, if you have that white space, it may not be an issue. If you can move 10% of your workload to specialty engines, the cost of an engine can be recouped in about 8-10 months. Generally, it is best to be able to offload about 20-25-30% of the GP to get your money's worth and not impact performance. Be aware your CPU time per transaction will go up anyway; while you throughput will increase. At that level, the potential to keep your software costs stable will be worth it. Please don't misconstrue this as being a negative. Specialty processors can be so worthwhile, if you plan properly and know what to expect. [email protected] Director, Product Management -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Ted MacNEIL Sent: Thursday, March 12, 2009 SYSN 01:01 PM To: [email protected] Subject: Re: TMON with OMEGAMON Comparison >But as others have indicated that offloading small percentages may actually increase the overall CP usage. "We all know..." "As others have said..." "May increase..." Yes, there is always overhead when one switches to another processor. And, yes, the reasons are understood. Without hard documentation, you are doing the same thing IBM used to do: sew FUD! What is this overhead? ---------------------------------------------------------------------- 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
