|
|
Why is the Unit Busy Pct for NPs always > 100%? |
|
|
This is normal behavior for a Unisys ClearPath A Series/MCP system. See the Symptoms and Cause below for details.
----------------------------------------------------
If I can't use "IO Busy Pct", how DO I determine the
actual utilization of my NP's ??????????
====================================================
The ViewPoint UNIT and SUBSYS statistics for NPs (Network Processors) are
IO Time statistics. Based on the Unisys technical definition of IO time,
they are correct. This definition is that IO Time is the time from when
the IO was handed to the DLP or Channel Adapter (in this case the NP) until
the DLP/Channel-Adapter completed the IO operation.
Due to the nature of MCP-to-NP message communication, this definition will
always result in odd IO times.
The whole concept of "IO Busy Pct" percent assumes that a unit's overall
"processing" capacity is limited by its "IO Time" capacity. While this
works for most IO devices, it does not work for the NPs where "IO Time" has
no relationship to their ability to "process" communication messages.
The real issue is to determine how "busy" the NP is. Hence, rather than
use the IO Time based variable "UNIT Busy Pct for NPxxx" to judge this, it
is far better to answer that question using the two BNALIB variables "BNAC
CPU Pct for host-icpxxx" and "BNAC Mem Pct for host-icpxxx" (ICPs are the
same things as NPs).
These BNAv2 variables show the actual internal CPU and Memory utilization
for the NP (ICP). They are much better metrics for judging actual NP
hardware utilization than the IO Time reported by the MCP for the NP.
Note that both the ViewPoint UNIT IO counts (UNIT IO/Sec) and BNA message
traffic statistics (BNAS MsgsIn/Sec, BNAS MsgsOut/Sec) are valid and either
can also be used to monitor the "processing" load on the NPs. |
|
|
When plotting "Unit Busy Pct" for your site's Network Processors, the values are consistently greater than 100%. The following variables are also much higher than the expected value range when referring to NPs:
IOP Busy Pct
IOP Idle Pct
IOP Q-Depth Avg
IOP Total IO Secs
Subsys Busy Pct
Subsys Idle Pct
Subsys Q-Depth
Subsys IO Secs
Unit Busy Pct
Unit Idle Pct
Unit Q-Depth
Unit IO Secs
|
|
|
The way NPs work is that the MCP queues a number of READ operations so that
the NP is then provisioned with a pre-allocated set of input buffers prior
to the arrival of data. As incoming messages are received, the NP simply
puts the data in one of the pre-allocated buffers and completes the IO read
operation.
The IO time for one of these read operations is the time from when the MCP
originally initiated the read (when it queued it to the NP) until the NP
puts data in the buffer and completes the read.
This technique makes the Q-Depth and IO Time/Busy Pct statistics
meaningless for NPs. The high queue depth indicates the MCP keeping the NP
stocked with input buffers. The IO time reflects the time these READ
operations sit in the IO Queue waiting to be used by the NP, which could be
a long time based on the rate of incoming message traffic.
The total IO time reported for an NP by the MCP SYSTEMSTATUS function is
simply the sum of the IO time for all the completed read operations. No
attempt is made by the Unisys MCP to edit out the "input wait time"
associated with these IO operations.
What ViewPoint does for all units is to calculate Unit Busy Pct using the
following formula:
(MCP reported Unit IO Seconds for the Sample)
---------------------------------------------
(Sample Elapsed Time in Seconds)
Hence, because the MCP reports extremely large phantom IO times for the NP
units, ViewPoint calculates percentages greater than 100%.
NOTE: MCP changes, implemented in the 44.x MCP releases, have modified
the NP management algorithms to dramatically increase the "reported" NP IO
time over that which was "reported" on pre-44.x MCPs. While the NP IO time
statistics have always been meaningless, sites may not have noticed the
issue until after coming up on MCP 44.x or later. |
|