Measure Reference Manual

where xx is the linker CPU number and yy is the listener CPU number.
• To support ServerNet cluster connections, the data in the linker and listener records have
changed to let the linker record (initiating processor) fully account for message traffic. This
support is accomplished by ensuring that both the linker and listener records count the same
number of message exchanges and corresponding bytes counts. The result of this change
allows for better accounting from the linker record because the listener record of a ServerNet
cluster connection will be in another node and not readily available in a Measure data file
from only one node.
• Listener READ-BYTES can exceed the corresponding linker record WRITE-BYTES. This condition
occurs in cases of frequent message system MQC allocation failure, which causes a retransfer
of the message data.
• For pre-push (non-ServerNet cluster) messages, the count of READ-REQUESTS is not incremented
in the listener record. The count of READ-REQUESTS in the listener record reflects the number
of message system pull operations performed and is a subset of the WRITE-REQUESTS counter.
The comparison of READS and READ-BUSY-QTIME provides an accurate measure of ServerNet
latency for pull operations.
• With ServerNet cluster (which does not pre-push messages), when the remote processor or
listener is trying to satisfy a WRITE-REQUEST and the messages are large, the number of
READ-REQUESTS can potentially be double the number of REQUESTS. For messages larger
than readlinkcache size (for example, larger than 2048 bytes), the listener process performs
two pulls: one for control and one for data.
• The SERVER-QTIME counter in message system listener records measures the time between
the receipt of a message by the listener processor and the subsequent reply. When used in
conjunction with the WRITE-QTIME counter in the associated linker processor record, this
counter gives a measurement of the ServerNet latency for message system transfers. Average
message latency can be calculated by subtracting listener record SERVER-QTIME from linker
record WRITE-QTIME, then dividing by the linker record WRITE-REQUESTS.
Calculating average message latency:
WRITE-QTIME(linker) - SERVER-QTIME(listener)/WRITE-REQEUSTS(linker)
• Measure does not coordinate measurement intervals between systems. To calculate the average
message latency between processors in separate ServerNet clusters, calculate the average
SERVER-QTIME and WRITE-QTIME values in a similar interval and then subtract the resulting
values.
• High values of the RETRIES counter are expected for connections to NonStop S70000 servers
(NSR-G processors). Defects in the ServerNet interface (MITE) for these processors are handled
through software recovery. These problems are fixed in the NonStop S72000 servers (NSR-T
processors), but the S72000 servers might still report high numbers of RETRIES when
communicating with NonStop S70000 servers (NSR-G processors).
• In some cases, when the remote processor or listener is trying to satisfy a WRITE-REQUEST
and the messages are very large, the number of READ-REQUESTS can potentially be double
the number of REQUESTS. For messages larger than readlinkcache size (for example, larger
than 2048 bytes), the listener process performs two pulls: one for control and one for data.
Usage Notes for CLIMs
• In Measure H03/J01 and later PVUs, Measure supports the CLIM node-class specifications
CLMI for IP CLIMs and CLMS for storage CLIMs. For these node classes, the optional fourth
specification after node-class is port. For non-CLIM node classes, it is subdevice.
In Measure H04/J02 and later PVUs, Measure supports the CLIM node-class specification
CLMO for Telco CLIMs.
CLIM is a wildcard for all CLIM node classes.
SERVERNET 333