Engineering - Part Two - Non-Integer Weights Are A Thing
MartinPacker 11000094DH Comment (1) Visits (721)
Maybe you’ve never thought much about this but aren’t weights supposed to be integer?
Well, they are at the LPAR level. But what about at the engine level?
Let me take you through a recent customer example. The names are changed but the numbers are real, as the one graphic in this post will show. The customer has a z14 ZR1 with 3 general-purpose processors (GCPs). The weights add up to 1000. Nice and tidy. There are two LPARs:
Both LPARs are in HiperDispatch mode - which means the logical engines are vertically polarised.
To proceed any further we need to work out what a full engine’s worth of weight is: It’s 1000 / 3 = 333.3 recurring. Clearly not an integer. How do you assign vertical weights given that?
Let’s take the easy case first:
TEST has a weight of 35. Much less than one engine’s worth of weight. It has two logical processors so we would expect:
So, in this case, both the engines have integer weights. So far so good.
Now let’s take the case of PROD. Here’s what I expect:
When I say “expect” I really mean “what I’ve come to expect”. And I say that because I’ve seen it in reports produced by my code - and ended up wondering if my code was wrong. With the “Engine-ering” initiative, and in general because of HiperDispatch, it’s become more important to understand what’s going on at the logical engine level.
Non-integer weights began to worry me. So I started to investigate. Here’s the process, in strict step order:
Let’s take a closer look at the record, which is what I did to establish Point 3.
When I look at individual records at the bits-and-bytes level I generally use RMF’s ERBSCAN and ERBSHOW execs:
I emphasise RMF because ERBSHOW does a good job on RMF records, but no so useful a job for most other record types. (SMF 99-14 is one where I’ve seen it do a good job, but I digress.)
Anyway, back to the point., Here’s part of an ERBSHOW for an SMF 70-1 record. It shows five Logical Processor Data Sections - the first 3 for PROD and the last 2 for TEST.
The highlighted field is SMF70POW - the engine’s vertical weight. Here’s the full description of the 4-byte binary field:
Polarisation weight for the logical CPU when HiperDispatch mode is active. See bit 2 of SMF70PFL. Multiplied by a factor of 4096 for more granularity. The value may be the same or different for all shared CPUs of type SMF70CIX. This is an accumulated value. Divide by the number of Dignoase samples (SMF70DSA) to get average weight value for the interval.
So the samples are multiplied by 4096. Now 4096 is 1000 hexadecimal. So an integer would end with three hex zeroes, wouldn’t it? The first three clearly don’t.
But lets take the simpler - TEST - case first.
Now let’s look at PROD.
So my code is vindicated. Phew!
My suspicion is that vertical weights are held (not just sampled) multiplied by 4096.
But in any case the message is if the data looks odd then dig into it. In my case I blamed my own tools first but my tools are vindicated. But my expectation was wrong or, more charitably, blurry.
And, the more I think about it, the more the actual engine-level weights make sense. They have to add up to the LPAR weight. And the existence of Vertical Highs forces the above arithmetic on us.
But half the point of this post is to show how I debug numbers (and names) in my reporting that don’t meet my expectation. And ERBSCAN / ERBSHOW is a pair of friends you might like to get to know.