2. PERFORMANCE REPORTING ANALYSIS › 2.7 Graphic Analysis › 2.7.4 I/O Tracking Graphs › 2.7.4.1 Device Response Components
2.7.4.1 Device Response Components
GRAPHIC RESULTS
This graphic analysis provides a stacked vertical bar chart
for each of one or more direct access devices that
experienced the highest queue times during the interval being
charted. The default is to plot only the device showing the
highest queue time, but you can choose to analyze more
devices per interval reported. The portions of the stacked
bar chart represent the average time for the four components
of I/O for the device. These components are queue time,
pending time, disconnect time, and connect time.
ANALYSIS GUIDELINES
The four components of I/O service time measured by MVS/XA
systems are:
o Queue - The average amount of time that I/O requests
to this device were held enqueued within IOS before an
SSCH instruction could be issued. Such an enqueue
occurs when this particular system already has an I/O
operation in progress on a device at the time another
I/O operation is requested by this same system.
o Pending - The time that the I/O was blocked by other
I/Os that used some part of the physical path to the
device. This can be caused by head of string or
control unit contention or reserve delays issued from
other systems. Pending time can also include the time
that the device was delayed due to an ESCON Director
(ESCD) port being busy.
o Disconnect - The time that the device spent in
seeking, in device latency, and in extra rotations due
to rotational positioning sensing (RPS) misses.
o Connect - The time that the device was connected to
the path. This includes the time required for both
channel control word (CCW) and data transfer.
The first three of these components can be addressed by
tuning. Excessive pending time may also indicate a need to
adjust the I/O load on the ES Connection Director ports. The
fourth component is a function of data set block sizes and
can only be addressed by changing the characteristics of the
data sets on the device. This last component is the only one
that actually represents the movement of data to or from the
device.
The queue component of I/O response time is the sum of the
time that the I/Os wait for the device's UCB (that is, device
busy condition) and the time that the I/Os wait for the LCU
(logical control unit) due to the utilization of the path by
other I/Os. If the utilization of the device is more than 30
percent, the I/O queue time can be reduced by spreading the
data sets on the volume across two or more devices. If the
device utilization is low, the only way to address I/O
queuing is to move the volume to a lower activity string.
The pending component of I/O response time represents the
average time between successfully issuing the start
subcommand (SSCH) to the logical control unit (LCU) and
acceptance of the first command by the device. Two factors
contribute to this delay. They are the utilization of the
path (for example, channels or control units) by other I/Os
from the system being measured, or device contention
conditions that result from I/Os issued by other systems.
These effects may be evaluated using the DASD Skew and Shared
DASD Analysis Reports of the Performance Manager.
The disconnect component of I/O response time represents the
portion of the device service time during which it is
disconnected from the channel. This time includes seek,
latency, and extra revolutions that result from RPS missed
reconnects. The value shown in the report should be compared
to the ideal disconnect time for the device type.
The ideal disconnect time may be calculated by dividing the
sum of the average seek time and rotational delay for the
device type by two. For example, the average seek time of a
3350 is 25 milliseconds and the rotational delay is 16.7
milliseconds. Therefore, the ideal disconnect time for 3350
type devices is approximately 21 milliseconds.
By comparing the ideal disconnect time to the actual for the
device, you can determine the impact of RPS missed
reconnects. If this time is significant, you can move the
volume to a less active device string where the RPS miss
contribution is lower. You can use the DASD Skew Report to
evaluate strings where RPS misses are causing performance
problems.
Delays due to ESCON director port busy occur when I/O actions
are delayed by the temporary unavailability of an ESCON
director port. Unless a dedicated port-to-port connection
from a channel to a controller has been defined within the
ESCON director, a port-to-port connection will be established
dynamically only for the duration of an I/O operation, with
the I/O processor requesting termination of the connection
upon I/O completion. A channel along which the I/O process
is initiated must pass a request that the ESCON director
establish a dynamic connection to any of the defined routes
to the device for which the I/O operation is intended. Each
controller attached to the device is attached to a port on
the ESCON director. If each of these ports is busy, an ESCON
port busy condition will occur.
If there is direct channel connection to a controller, ESCON
port delays are not possible.
It is also possible to link two ESCON directors, for
instance, to increase the distance permitted between
processors and devices. If this has been done, the link
between the directors may also be a source of contention for
which the port busy condition will occur.
You can determine the presence of ESCON port delays by using
the I/O Component Report of the MVS Performance Manager.
The detailed behavior of I/O devices can be further analyzed
using the I/O Configuration analysis reports described in
Section 2.4.
SPECIAL CONSIDERATIONS
This graphic analysis uses information that became available
with the advent of MVS/XA, so you will not be able to perform
this analysis for a system unless it is operating at MVS/XA
or beyond.
