Communication Performance Problems

Performance problems are normally indicated when response times seem slower than usual, or when it takes an excessively long time to send a given amount of data from one place to another. Before examining how tsgstat and tsgtrace can be used to find a throughput problem, consider these questions:

Does the problem get worse when other people start using virtual circuits on the link?
If not, then the link is not likely to be the cause of the problem.
Is the problem dependent on the time of day?
If so, the problem may be the result of daily peak usage on the packet network.
If there are other users connected to your machine, but NOT connected via Netcom II, are they also experiencing performance problems?
If so, the problem may be related to the OS rather than Netcom II.

Communication Line Problems

The software provides a number of indications that there may be a faulty facility (communications line) between the card and the network node to which it is connected.

Numerous frames arriving with CRC errors and abort sequences indicate that the data from the remote system is not arriving error-free. This may be a result of a "noisy" line where some kind of electrical interference in the path causes data to be altered during transmission.

X.25 frame level statistics also provide clues to the quality of the signals exchanged on the communications circuit. T1 timeouts, REJ frames transmitted and received, and abort sequences transmitted are all mechanisms used for recovering from CRC errors. If these counts are constantly incrementing (a few times per second), there is likely to be a facility problem which is having a detrimental effect on throughput.

X.25 Insufficient Buffer Space

When an RNR is received, it indicates that the remote X.25 node is having problems with the data flow, because data is being supplied faster than the remote system can handle it. You need to discuss this with your network service provider.

If the remote system does not implement the RNR response to an I frame, insufficient buffer space on the part of the remote system may manifest itself by window closure. When this occurs, you will see the local node send a window's worth of I frames (k frames) without receiving any frames which rotate the frame level window. You'll see this in the frame log if there are "k" I frames transmitted ("I(r,s) hh hh hh . . . ") with incrementing values for "s", BUT the received "RR(r)" and/or I-frames will show a constant value for "r".

Some equipment does neither of these things. When the switch decides that it has insufficient buffer space, it clears some of the calls that are up, giving network congestion as the reason code. Such behaviour represents an incorrect implementation of X.25 and should be discussed with your network provider.

Link Too Slow

If performance problems are associated with increased use of virtual circuits, it may be that the link is overloaded. To assess whether you need a faster link, use the procedure described below. Note that this procedure represents a set of general guidelines. If you are new to data communications, you may wish to obtain the assistance of an experienced communications analyst.

Obtain a watch with a second hand.
Set up whatever combination of applications and terminal sessions are required in your environment to recreate the performance problem.
Calculate your link speed in bytes per second (for example, a 9600 bps link translates to 1200 bytes per second).
Look at the Transmission Statistics from tsgstat and record the "bytes transmitted" value.
Record the time on your watch (seconds only).
Repeat the previous two steps for "bytes received" (Reception Statistics).
Repeat both measurements several times over the course of the next few minutes.
Examine the frame log and frame statistics to ensure that there are no excessive error counts or abnormal protocol sequences.
Using the recorded times and byte counts, calculate average throughput per second for both the inbound and outbound sides of the link (divide total byte count by total seconds).
Determine what percentage of maximum theoretical throughput this number represents (divide the number by link speed and multiply by 100).
If your calculated percentage is in the 90 to 100 percent range, it is likely that your link speed is too slow for your traffic requirements.

If your performance problem is poor response time, keep in mind that interactive response times, while dependent on many factors, are rarely fast when messages have to traverse heavily utilized links. You may wish to experiment with link utilizations as low as 35%, depending on message lengths, to achieve your response time targets.

Always bear in mind when using shared packet networks, that the source of performance problems may be your local link, the remote link, or the internal packet network itself. Furthermore if you are running sessions across interconnected packet networks, additional delays may be imposed by the network "gateway". If you have eliminated your local WAN link as a source of performance degradation, these are other avenues to pursue.

Revision 1.1 (January 2002)