Network performance and tuning

When a situation arises where network performance (often throughput, but sometimes response time) does not meet expectations, the first step is to perform problem source identification, as discussed in this section. However, what happens if no "problem" is actually identified? Such a case can happen when the problem is a function of network performance.

Factors that can affect network performance are:

Maximum transmission unit: How large can the largest packet be? Is such a packet going to be fragmented on the network?
Link speed: How much throughput is available, either as a function of the adapter speed itself or else residual throughput of an adapter that is already carrying other traffic?
Network latency: How long does it take data to make the round trip between the endpoints?

Other factors can obviously come into play that are actually outside of the network. For example, how quickly can the endpoint applications respond to packets coming from the network?

Note: TCP/IP's dispatching priority (the relative rate at which it is allowed to consume system resources) should be on par with VTAM dispatching priority, which effectively means it should be in the highest service class available. The same goes for critical, time-sensitive, servers like OMPROUTE.

Of course, some network performance problems can be understood to some degree using a simple packet trace. For example, there are fields such as round trip time (RTT) which provide an accurate estimate of the time it takes a packet to travel out and back along the connection. In addition, the throughput section identifies the basic data throughput characteristics of the connection.

Using a packet trace to analyze network performance, however, is not the right tool for the job. There are many available network performance analysis tools that can reveal details of a network's performance that a packet trace could never identify.