2. USAGE CONSIDERATIONS › 2.3 Use Within the Information Structure › 2.3.4 Installation Environment Analysis › 2.3.4.3 Environment: Performance Management › 2.3.4.3.4 Performance Analysis

2.3.4.3.4 Performance Analysis

 
One of the most significant components of network response
time is the delay between the time you press ENTER on the
terminal and polling of the terminal.  This delay is called
"wait for poll." The length of the wait for a poll is a
function of the polling rate of the line and the number of
terminals that have outstanding requests for service.
 
These effects can be seen in the following example:
 
    Assume that there are two cluster controllers (SNA PUs)
    on a peripheral link.  Each controller has fifteen 3270
    devices attached to it.  The link polling rate is twenty
    polls per second.  If, on the average, two-thirds of the
    terminals have outstanding requests at any one time, each
    terminal will be polled approximately once a second
    (ignoring any data transmission time).  In this case,
    network response time would always be greater than one
    second.
 
From this example, it is clear that a low polling rate can
significantly affect response time, but a high polling rate
also effects negatively on response time.  High polling rates
cause communications control unit utilizations to increase
out of proportion to the amount of data transferred.  It
requires many more CCU instructions to generate a given level
of link utilization through polling than to generate the same
utilization level through data transmission.
 
Neither NetView Session Monitor/NLDM nor NPM nor CA NetSpy
measures the response delay incurred by wait for poll;
therefore, the choice of a polling rate for a line must be
made somewhat by trial and error.  As a rule of thumb, a link
should be polled at least once per second per active device.
The adequacy of the polling rate can then be judged based on
the percentage of positive and negative polls.  The optimum
positive and negative poll percentages can be judged based on
the average time between end-user commands (user think time).
If there are twenty terminals on a link that is being polled
twenty times a second and the average user think time is
twenty seconds, there should be at least one outstanding
request every second; so that one poll, or five percent of
the total, would be positively acknowledged.
 
Polling statistics are displayed on the NCP Utilization
by Link report that is described in Section 3.1.3.2.4.