MVSFORUMS.com

[RichInFlorida]

I've got a service provider telling me that he is providing me a certain level of MIPS and I think he isn't. We've gotten the issue distilled down to a fairly simple model, using a Z/series 2064-104 with 4 LPars defined. Each LPar has 1 LCP defined that can dispatch on all 4 CPs. Each LPar is weighted at 250. We both agree that each CP is capable of 239 MIPS which degrades to just over 207 with all 4 processors active.

His contention: Each LPar will get the full 239 MIPS capacity of a processor regardless of the load on the box.
My contention: Each LPar will not get the full 239 MIPS. The only way to get a guaranteed 239 MIPS is to dedicate a physical processor to an LPar.

He can show me that my LPar is getting considerably in excess of 207 MIPS on occasion and I believe that will only happen when the overall load on the box is light and I am consuming 'free' MIPS off other LPars. When the load picks up, the machine will move toward its weightings.

He contends that the MP factor is only an issue within an LPar, as more processors are defined to run within the SAME LPar....so it follows, he explains, that 1 LCP in my LPar will provide 239 MIPS regardless of the workload on the machine.

His theory generally holds that the overhead that degrades processor output is generally incurred in an LPar, NOT outside of it. Using the 2064-104, he states that the configuration above will provide about 948 MIPS (239 * 4 less some amount of PR/SM overhead) and NOT the 829 which is generally accepted as the rating for that frame.

I could learn a lot about machine organization with this little problem.

[kolusu]

Richinflorida,

Please search before posting. This topic has been covered earlier. Check this link

http://www.mvsforums.com/helpboards/viewtopic.php?t=1203&highlight=mips

Also check the following links which might be quite useful

http://www-1.ibm.com/servers/eserver/zseries/srm/

http://www-1.ibm.com/servers/eserver/zseries/zos/wlm/documents/sample/samplepol.html

Hope this helps...

Cheers

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu

[RichInFlorida]

I DID search.

That post does not address the question...really in any way.

My question is based on the ratings system by IBM and the effect PR/SM has on the processor allocations in an LPar.

Honest!

[semigeezer]

I'm not sure these answer the question, though they hint at a portion of the answer. I don't know how LPARs play into it, but you certainly will not get the full power of the processor for one simple reason -- interprocessor cache validation. If you are running multiple processors, each has an L1 and L2 cache and those caches can contain references to the same memory location. If they do, it can take a couple of cycles to invalidate the line in the containing cache when another processor needs to update that memory location. I assume that is still true, and the charts that K referenced seem to indicate that it is. It certainly was a significant factor when I was working with the 3090 design team doing cache-miss simulations. That was 20 years ago and there have been significant improvements since then so I couldn't hazard a guess on the penalty these days. Back then it was the main reason there were 4 way processors and not 32-way ones. After about 4 or 8 processors, all benefits of additional processors were overshadowed by interprocessor management.

[RichInFlorida]

No doubt that what you describe is the premise upon which the final answer is based.

The contours of the problem revolve around how much of the overhead you speak of (and its ilk) is related to processor to processor coordination WITHIN an LPar and how much is incurred outside of the LPar.

I suspect much is within the LPar as processors within the same LPar are likely to be making common references to storage.

It is also interesting to note that IBM states in the LSPR (large systems performance reference) that benchmarks are NOT taken in partition (LPar) mode. Which infers 2 things..

1) It is better to run in basic (non-LPar) mode and
2) The numbers they state cannot be effected by LPar processing because they don't use it for the benchmark.

Thanks for the help.