Perhaps this is why

My apologies, but I must start by spending a few lines explaining something that may seem a bit technical, but which is actually pure logic (and the basis for understanding one of the trickiest problems in mainframe outsourcing today).

Here we go.

IBM’s seemingly eternal quest to maximize mainframe performance does not limit itself to improving the speed of hardware. On the contrary, the now four generations old EC12 was equipped with the fastest IBM processors yet (and probably still the fastest overall not conveniently submerged in liquid nitrogen).

So how can new mainframe models keep increasing processor power (the number of MIPS, MSUs, or whichever yardstick you prefer, per processor)?

There are several answers to this question. The two most common are:

  1. By improving the pipeline (there are processors in a mainframe doing nothing but arranging and aligning instructions and data for the “real” processors)
  2. By improving the sourcing of Level 1 Cache (that small amount of extremely fast memory that the processor is actually able to access directly).

But once in a while a new idea comes along as an addition to the usual improvements. And so it is with Processor Vertical Affinity (patience please, we’re getting closer now).

Vertical Affinity is nothing new, but so far only true nerds seem to worry about it – so to keep a long story short, this is what it’s all about:

  • The hypervisor (the thing deciding which virtual server = LPAR will be receiving resources) will try to dispatch 1 Logical CPU on 1 Physical CPU (the very same) only
    • This is called a HIGH CPU and is a performance advantage for the Logical CPU of a magnitude not seen since the invention of virtualization
  • If this is not possible, the hypervisor will intelligently group some Logical CPUs together to share some Physical CPUs
    • These are called MEDIUM CPUs and for some reason a collection of 4 Physical CPUs seems to be preferred
  • If this is also not possible, Logical CPUs will be dispatched on any available Physical CPU (OK, only on a HIGH if it has not been used for a long, long time)
    • These are called LOW CPUs and they will often have the highest overhead – why ?
    • Because all their stuff (instructions and data) was probably left with another Physical CPU the last time they were interrupted.

Two things are noteworthy (and we’re almost there):

  1. It is of course not possible to have all HIGH CPUs because of the Logical-to-Physical ratio brought on by virtualization (there are many more Logical than Physical CPUs)
  2. The number of HIGH, MEDIUM and LOW per LPAR is decided based on LPAR Weight (the guaranteed capacity when the entire mainframe is 100% busy) and the number of Logical CPUs

So now it is time to ask: who benefits from Vertical Affinity (HIGH, MEDIUM and LOW CPUs)?

  • Well, if you are among IBM’s top 500 customers you probably have a number of giant mainframes with at least one huge production LPAR on each (with lots of HIGH CPUs), probably a development or test LPAR (with a mix of affinities) and perhaps a sandbox LPAR (with a MEDIUM and some LOWs). A perfect situation, optimizing the environment for production.
  • So, what if you’re sharing some outsourcers mainframe with a number of other customers ? Well, the affinity you end up with depends on the relative size of your LPAR(s) – relative to all the other LPARs on the same mainframe. Which ultimately means that the arrival of a new customer (or changes to the configuration of an existing one) could change your CPU affinities.

This picture (based on real life measurements) shows a clear connection between LPAR Weight and Processor Vertical Affinity:

This picture (based on real life measurements) shows a clear connection between LPAR Weight and Processor Vertical Affinity

Fig.1 Connection between LPAR Weight and Processor Vertical Affinity

Now, finally, here’s the point of all this tech talk: at current customer sites we have seen indications that such changes may increase the usage of MIPS, MSUs, CPU seconds, and so on, by more than 10% – and that’s for doing exactly the same work.

And remember, this is not the outsourcer trying to cheat anyone – this is just the outsourcer trying to make everybody happy and keep a certain balance in a shared environment.

Give us a call if your invoice seems to be increasing for no particular reason. You might be just a slight adjustment of parameters away from substantial savings.

by Jens Olesen, ITBI Director

Jens Olesen, ITBI Director

Jens Olesen joined SMT Data in 2007. His main focus is helping customers maximize the benefits of using ITBI. Before joining SMT Data, Jens has worked as consultant for various international financial institutions. He has an extensive experience in technical architecture and cost optimization of infrastructure, middleware and applications on different platforms.