2. USAGE CONSIDERATIONS › 2.4 Specialized Analysis
2.4 Specialized Analysis
This section describes analyses you can perform using the
data from the CA MICS Network Analyzer Option's files.
Estimating Backbone Network Communications Capacity:
Background
----------
The communications controller subarea nodes that are
channel-attached to host processors and the links that
interconnect them make up what is loosely termed the
"backbone" of a network. It is through these communications
controllers and their associated links that the bulk of the
network traffic (to and from the mainframe applications)
ultimately flows. This concentration of load means that
inadequate capacity in the network usually occurs first in
the backbone.
Obviously, any significant increase in overall network load
will affect the backbone elements, but normal network
maintenance can significantly affect the backbone's load
carrying capacity. In some cases, relatively minor NCP
generation parameter changes can have drastic effects on the
utilization level of communications control units (CCUs).
This is because small changes to buffer lengths or negative
poll delays can greatly increase the average number of CCU
processor instructions required to transmit a byte of data.
Methodology
-----------
One way to quantify the effects of NCP gen changes is to
track the mean instruction path length-per-byte of data
passed through each CCU. The mean instruction path length
varies with the traffic mix but is relatively invariant under
load. Therefore it is unnecessary to ensure that exactly the
same load exists on the processor as long as the traffic
mix is the same. To ensure that the mix is homogeneous,
observe the following rules of thumb:
o Always compare path length measurements from the same
times in the processing day.
o Always compare the same days in the processing cycle
(for example, month-end to month-end).
o Avoid comparisons where new applications have been added
unless you have verified that the new applications do not
change the traffic mix. (Refer to Application below.)
Determine the total amount of traffic passing through a CCU
during the period of interest. This can be done by
summarizing the Number of Bytes Sent (CAFNRCHS) and Number of
Bytes Received (CAFNRCHR) fields from the SNTCAF File for the
particular CCU and time period of interest.
Determine the number of instructions executed by the
processor in the CCU during that time period by multiplying
the processor instruction rate by the length of the time
period of interest.
Divide the total number of instructions available by the
number of characters passed to obtain the mean instruction
path length per byte. This number is the approximate number
of processor instructions required to move a byte of data
through the CCU and is generally on the order of 100
instructions per byte.
To be rigorous, the number of instructions lost due to cycle
stealing should be calculated. These cycles cannot be used
by the processor because Type 2 and 3 channel adapters
preempt it to transfer data to and from storage. The number
of stolen cycles can be calculated by estimating the number
of bytes transferred to and from the channel adapter (CA) and
multiplying them by the number of cycles the CA requires to
transfer a byte of data. The total number of stolen cycles
are then subtracted from the total number available before
dividing by the total traffic. In practice, this adjustment
is generally very small.
Application
-----------
Because the mean path length-per-byte is largely sensitive to
traffic mix only (for a given set of NCP gen parameters) it
can be used to estimate the capacity of a CCU handling that
traffic mix. That is, the data handling capacity of a CCU
per unit time will be approximately the CCU's processor
instruction capacity-per-unit-time divided by the mean
instruction path length-per-byte. This estimate has been
shown to be surprisingly robust in widely varying
environments.
Often estimates of capacity are made by assuming that traffic
generated by a new application will place much the same load
on the network backbone that existing traffic does. That is,
that the mix of the new application's traffic is the same as
the mix of the existing applications' traffic. By isolating
the new application in a test environment and computing the
mean instruction path length-per-byte, the validity of this
assumption can be tested.
Before and after comparisons of the mean instruction path,
length-per-byte should be made for each new NCPGEN. This
comparison will quantify the cost in backbone capacity of
supporting new facilities or, conversely, the benefits
derived from NCP tuning. Most importantly, it will prevent
the network analyst, who is removed from the day-to-day NCP
gen process, from being surprised by an unexpected reduction
in backbone capacity.
Basic Network Accounting Background
-----------------------------------
Historically, billing for network resources has been largely
relegated to the few adventurous organizations that dared to
experiment. Now, the information in the CA MICS Network
Analyzer Option and the billing facilities of the CA MICS
Accounting and Chargeback Option can be combined to offer a
network accounting approach that will satisfy the basic
requirements of many enterprises.
Basic network accounting is supported for multiple
information sources: CA NetSpy terminal data, and network
session accounting data/network gateway accounting data,
Tivoli NetView Performance Monitor (NPM) session data, NPM
network session accounting/network gateway accounting data,
NetView Session Monitor Response Time Monitor (RTM) data,
NetView Session Monitor accounting and availability data,
CA NetMaster RTM data and accounting data. Since there is an
overlap in information provided by these sources, the
decision on which sources to use is governed by the needs of
the enterprise, the specific information available from each
source, and the operational costs associated with each
network monitor.
Since more than one network monitor can collect data for the
same session, it is possible for you to develop a billing
scheme that causes duplicate billing for some sessions. For
example, if you are billing for session connect time or
characters transmitted based on information from both NPM and
NetView, you can end up billing some users twice for the same
session activity. You should carefully evaluate these
considerations when constructing a billing scheme based on
network monitor data from more than one source.
Billing is supported for connectivity to specific network
resources, session duration, and character traffic for
terminals or groups of terminals in session with specific
applications. A differential charge can be assessed for
different classes of service, local or remote attachment,
transmission priority, explicit route, virtual route, or any
of several other service or configuration related factors.
Accounting Information Sources
------------------------------
The basic network accounting approach supported by the CA
MICS Network Analyzer Option and the CA MICS Accounting and
Chargeback Option uses data from the following information
sources:
o CA NetSpy Network Session Accounting
o CA NetSpy Network Gateway Accounting
o CA NetSpy VTAM Interface: Terminal Activity
o Network Performance Monitor (NPM) Session
o NPM Network Session Accounting
o NPM Network Gateway Accounting
o NetView Session Monitor Response Time Monitor
o NetView Session Monitor Accounting and Availability
o CA NetMaster NTS Response Time Monitor
o CA NetMaster NTS Accounting
These sources provide different views of the data and permit
different ways of performing network accounting. There are
six CA MICS files that contain data from these sources, and
which can be used for accounting:
o NCP Network Accounting (SNTNAC) File
o CA NetSpy Terminal (SNTNSS) File
o NPM User Activity (SNTPSU) File
o NLDM Session Accounting (NVSNSA) File
o NLDM Session Connectivity (NVSNSC) File
o NLDM Response Time (NVSRTM) File
Each of these files is described in Chapter 5, along with a
list of the data elements associated with each file. See
Appendix B for a description of specific data elements and
their use within each file. This overview should help you to
select the information appropriate to your billing needs.
Differential Billing
--------------------
A standard requirement for resource billing is differential
charging based on service or configuration.
The user with a locally-attached terminal can be charged a
premium versus the user with a remotely-attached device since
the locally-attached terminal provides faster response time.
Or, based on the additional cost of the facilities for a
remotely-attached user, the differential can be applied in
exactly the opposite way.
To accommodate this requirement, logical unit-to-logical unit
(LU-LU) sessions are distinguished as local, remote, or
application-to-application (APPL-APPL) by the CA MICS Network
Analyzer Option. Other session types (for example, system
services control point to system services control point (SSCP
to SSCP)) are designated as "other." Users of the CA MICS
Accounting and Chargeback Option can, through a special
feature called XMITTYPE, set different rates for each
billable element depending on whether the session is local,
remote, or APPL-APPL. For example, the cost for
locally-attached devices could be set at $.04 per thousand
characters, while the cost for remotely-attached devices
could be set at $.02 per thousand characters.
The method used by CA MICS to distinguish local, remote, and
APPL-APPL sessions is described later in this section. If
you choose this billing approach, be sure to read this
section before you finish installing the CA MICS Network
Analyzer Option.
In addition to this facility, CA MICS provides for
differential billing based on other service and configuration
considerations. For example, this capability could be useful
for an enterprise that assigns a surcharge to network traffic
with a higher priority, and therefore faster service.
One way to assign different priorities to different types of
work in a network is to use transmission priorities.
Transmission priorities can be assigned to different classes
of work so that, for example, interactive traffic receives a
higher priority than batch traffic. Transmission priority
values of 0, 1, and 2 can be assigned, with 2 representing
the highest priority.
In the example where interactive and batch are assigned
different priorities, you can assign to interactive the
highest priority of 2, and to batch the lowest priority of 0.
You can apply a factor to charges for interactive traffic
that result in their cost per thousand characters being 1.5
times the standard cost, which is applied to batch traffic.
The way to implement such a billing strategy using the CA
MICS Network Analyzer Option is through the Network Service
Group facility (NETGROUP) described in Section 7.3 of this
guide.
Identifying Local Versus Remote Sessions (fffLDEV)
--------------------------------------------------
Because most CA MICS Network Analyzer Option data sources
(excluding NPM) do not identify sessions as local or remote,
CA MICS determines this information from the data available.
The approach taken is to compare primary to secondary subarea
identifiers (NPM) and primary and secondary subarea physical
unit identifiers (NetView and CA NetMaster). When the
identifiers are equal, the session is considered to be a
local session. When the identifiers are unequal, the session
is considered to be a remote session.
As an exception, to account for logical unit-to-logical unit
(LU-LU) sessions in which the secondary logical unit (SLU) is
an application, you can designate a list of applications that
can participate in APPL-APPL sessions by coding the
application names in prefix.MICS.PARMS(NETAPPL). The CA MICS
Network Analyzer Option identifies any session whose SLU is
found in the NETAPPL table as an APPL-APPL session. NETAPPL
is described in Chapter 7. Sessions that are not LU-LU, such
as system services control point to physical unit (SSCP-PU)
sessions, are identified as "other" sessions.
A local device flag data element is set to indicate local
(L), remote (R), APPL-APPL (A), or other (O) in these files:
o SNTNAC file (NACLDEV)
o SNTPSU file (PSULDEV)
o SNTNSS file (NSSLDEV)
o NVSNSC file (NSCLDEV)
