A Note On Velocity
MartinPacker 11000094DH Visits (5624)
Not to be confused with Notational Velocity.
A recent customer situation reminded me of how our code calculates velocity. It’s worth sharing with you.
The standard way of calculating velocity is to compute
(Using Samples)/(Using Samples + Delay Samples)
and convert to a percentage by multiplying by 100.
The numbers are all recorded in SMF Type 72 Subtype 3.
We have two main graphs associated with Velocity for a single service class period:
You would expect the two graphs to agree - with the Using Samples as a proportion of the whole similar to the velocity data points. Indeed I hadn’t questioned that until this situation.
The surprise was that the Using Samples suggested a far higher velocity than that we computed. In detail, the Using Samples were dominated by Using I/O.
The surprise was only momentary because our reporting also tells us that in this sysplex I/O Priority Management is disabled. This is unusual in my experience and one implication is that neither Using I/O nor Delay For I/O samples are included in the velocity calculation.
So why did my velocity calculation work? It’s because we use two key fields in the SMF 72–3. They are the headline Using (R723CTOU) and Delay (R723CTOT) Sample counts - which reflect how WLM itself calculates velocity. We don’t use the individual Delay an Using sample counts e.g Delay For CPU (R723CCDE) or Using zIIP (R723SUPU) in the velocity calculation.
A few things flow from this:
But those ideas are for another day or, more likely, another year (it being December now).
But let’s look at a worked (real) example. This is summing over 1 hour for the “DB2STC” service class for 1 system.
The headline sample counts in that hour are:
If you calculate the velocity it’s about 45%. Also Using + Delay is about 6%, fairly typical for this kind of work, the vast majority being Idle.
Breaking down Using and Delay samples, using the explicit fields in 72–3:
The above doesn’t include Using I/O and Delay for I/O but the samples included do add up to the headline numberss. I’ve also excluded any zero-value counts, including “Using zIIP on CP”.
Now here are the I/O related sample counts:
If these samples are added in the resulting velocity is 91%. In fact the goal is Importance 1, Velocity 70% - so the goal would be easily met if I/O Priority Management were enabled.
But that doesn’t necessarily mean better performance: Up to a point CPU queuing would be masked by the very strong Using I/O component. But a revised goal of, say, Importance 1 Velocity 90 with I/O in might be better.
Food for thought.