SNA Communications Server tuning for Horizon

Overview

SNA Communications Server (formerly VTAM) network performance tuning includes the monitoring of response times and network loads, and the adjustment of SNA Communications Server, NCP, and application variables. The goal of the tuning is to improve response time and allow for greater capacity.

Although SNA Communications Server tuning necessarily involves the SNA Communications Server system programmer, some of the variables that can be tuned to increase performance have to do with the SNA Communications Server definitions discussed in Defining the network to SNA Communications Server. Three of those variables (associated with the APPL statement and the mode table) are briefly discussed in this appendix:

• Chaining and RU sizes
• Session-level pacing
• Transmission priority and route selection

Chaining and RU sizes

In the mode table entry for Model 204/Horizon supplied in Defining the network to SNA Communications Server, the RUSIZES parameter (maximum secondary LU send RU length, and maximum primary LU send RU length) is coded to restrict RU lengths in both directions on the session to 2K (2048) bytes. The two 1-byte values are coded in normalized floating-point notation, in the form:

m * 2n

where m is the first digit of the value and n is the second digit. Thus, x'88' is 8 * 28, or 2048. These values are suitable for most applications.

The restrictions on RU sizes for a session compel the session partners to segment messages exceeding the maximum into smaller elements "chained" together.

When to chain

Chaining is a common means of achieving better performance in SNA networks for the particular circumstances described below. When these circumstances apply, it may be advisable to lower the RU maximums in order to attain more chaining.

The first of these circumstances pertains to network topology and the second pertains to Model 204 system resources.

• When a network contains remote NCPs (that is, multiple "hops" between source and destination), connected by relatively low-speed lines, transmission delays can be greatly reduced by ensuring that the message units being transmitted are small. Chaining of application data accomplishes this since one chain element at a time is transmitted.
• When the Model 204 ONLINE running Horizon conversations is virtual-storage constrained and at the same time required to support a significant number of conversations concurrently, efforts should be taken to reduce the buffer requirement for those conversations. For each active, concurrent conversation, Horizon allocates as a common buffer (for data sent and received) the larger of the following values:
  • Maximum primary send RU size
  • DEFINE PROCESS DATALEN= parameter value

  This buffer is allocated for the duration of the conversation.

  For example, if the largest message expected from a partner across all processes is 1K bytes and the table entry still calls for a maximum send RU size of 2K, the buffer allocated for each conversation in Model 204 is at least 1K larger than actually needed. If it becomes necessary to conserve virtual storage, setting maximum RU sizes to 1K in the mode table entry for Model 204 causes Model 204 to allocate just 1K for each buffer, resulting in a savings of 1K per active conversation.

Note: Unless you are sure that the expected messages in the two directions between the ONLINEs will be unequal in length, keep the values for both secondary and primary LU the same, rather than paring down the values separately as much as possible: Horizon returns a "DATA TRUNCATED" error code to the application process when the process receives an application message larger than the buffer it has allocated.

If, on the other hand, the sending side has a maximum RU equal to this receiving side's buffer, the large message is sent as a chain of smaller elements, each of which fits into the receiver's buffer.

Chaining and CPU usage

Message chaining has a cost: CPU usage. Chaining means multiple sends per message, whereas only a single send is required when the message is sent in its entirety as a single unit. More CPU cycles are needed to accomplish the multiple sends. The network tuner must check to make sure that CPU usage by Model 204 has not increased significantly by the level of chaining introduced.

Session-level pacing

Session-level pacing is an important means of protecting internal network components from overload by individual users. An operand of the APPL statement and an operand of the mode entry statement combine to specify the session-level pacing parameters.

Pacing parameter settings

In the samples provided in Defining the network to SNA Communications Server, the flow control, or pacing, variables are set to 5 in both directions. The SNA Communications Server on the sending side forwards no more than five messages (message chain elements, actually) on a single session involving this Horizon "link" to the SNA Communications Server of the receiving side, until an internal acknowledgment (a "pacing response") is received from the sending SNA Communications Server.

Usually there is no need to alter this value. The setting of 5, in conjunction with the large maximum RU size of 2K, protects the network from long chains of data without slowing down the flow of average-length data.

Modification of pacing parameter values

Pacing values may be reconsidered if, perhaps for reasons outlined in the discussion above on chaining, the maximum RU sizes are reset to values much smaller than the average application message length. The pacing values should then be set higher to avoid unnecessary throttling of the conversations.

Transmission priority and route selection

This network performance topic is directed at the network planner, the person doing the initial preparation for inter-computer traffic. The objective is to prevent network batch transmissions from disturbing shorter, network interactive transmissions.

Horizon transmissions are usually the interactive type: a user triggers a remote process by opening a local process through terminal-entered commands and waits at the terminal for the remote process to complete. If interactive transmissions experience transient delays, at least some users are disturbed. Transient delays of batch transmissions (such as file transfer), however, are unobserved and overall turnaround time is instead the performance criterion.

Transmission priority refers to NCP's ability to prioritize transmission across NCP-to-NCP lines. Route selection refers to the ability of both SNA Communications Server and NCP to force different sorts of traffic onto logically distinct and independently managed "virtual routes." Network planners can take advantage of these facilities to allow interactive traffic to be transmitted ahead of, or on lines different from, batch traffic.

Assigning transmission priority and route selection

When a computer network sporadically transmits large amounts of data of a systems nature (such as job output) between the computers, an operating-system level subsystem, such as JES or RSCS, is typically used. The network planner uses the mode table entries for those subsystems to associate the batch traffic they send with yet another network table, the class of service (COS) table. The COS= operand on the MODEENT macro refers to the name of the COS table entry. Entries in the COS table determine transmission priority and route preference.

A special entry can be assigned to these batch transmission subsystems so that their traffic flows at a lower priority than, or separately from, Horizon interactive traffic. The Model 204/Horizon mode table entry (and entries for online systems generally) can then assume, by omitting the COS= operand, an association with the "default COS table entry," which is coded so as to designate a high priority transmission.

Horizon batch transmissions

Horizon processes can also involve batch transmissions. For example, applications can be written to periodically transfer Model 204 audit trails between systems for merger at a central point.

To separate such applications from interactive ones, the performance tuning technique is to include a COS= operand in a new mode table entry for the Horizon systems involved in the application. The Model 204 DEFINE PROCESSGROUP MODENAME= parameter can then be used to call for a session with the special routing characteristics desired when the audit-trail transfer application process is started.