WHY IS A TUNED STACK IMPORTANT?

An ideally tuned TCP stack transmits information to the network exactly as fast as the network can transmit it, allowing for maximum network throughput while avoiding congestion management algorithms that could result in poor throughput. The ideal stack will balance good network performance against system resources. If sized too small, the TCP stack constrains network performance at the host. If sized too large the stack could leach system resources or oversaturate the network path, requiring the network to queue or drop packets along the way.

While network engineers may configure equipment to use queueing and dropping as congestion management strategies for the overall benefit of the network, the effect of a dropped packet on a single host's network performance can be detrimental. Packet queueing occurs when packets arrive at an outgoing interface faster than they can be transmitted. The device must store the packets somewhere while it waits to forward them. If the device runs out of queue space, it must drop the packet, resulting in packet loss. The TCP algorithm requires every packet to arrive, so once dropped the source host is required to retransmit. While some retransmission is acceptable in most environments, excessive retransmissions in any network are ultimately detrimental to network efficiency as the network must devote time and resources to passing the same data several times.

While it is possible to make the queues on the network devices bigger, increased queue depth means that packets spend more time waiting to be transmitted, resulting in longer transit times across the network. This transit delay is called latency, and is one of two factors that directly affects network performance. Another effect of queueing is the introduction of jitter into the transmission. If latency is the transit time across the network due to the effect of queueing, then jitter is variation in the latency of individual packets due to real-time network factors. Together, latency and jitter are two of the most important factors in the performance of real time network applications such as IP Voice and IP Video.

The Network Diagnostic Tool (NDT) is used to help tune the TCP stack to maximize throughput to and from your host, while avoiding over-saturating the network path and introducing loss, latency and jitter resulting from packet queueing. NDT is client-side Java applet that works with a testing server to observe the transmission characteristics of the network path between the two systems. It provides quantitative feedback to aid in adjusting stack parameters to make the most efficient use available network bandwidth and host resources. The test may also identify common networking performance problems such as duplex mismatch, out-of-order packets, and excessive retransmissions.

TEST REQUIREMENTS

NDT makes several assumptions about its runtime environment. In order to ensure the most accurate results, the user should ensure that

1. if there are any firewalls in the network path, that they do not actively block ports TCP/3000 through TCP/3003,
2. that all other programs are closed before an NDT test run is started, and
3. that no other traffic is using the host's network connection when an NDT test is started

TEST INSTRUCTIONS

To initiate a test, access the web page on the desired NDT server and click the "Start" button when the applet loads. A typical test run takes 30-40 seconds while the tool gathers path and performance information. When the test completes, the applet reports on the observed throughput for both uploads and downloads, as well as other observations on the network path characteristics. The tool will also report on errors, or significant deviations from expected performance if they are observed.

• NDT Server in New Brunswick/Piscataway
• NDT Server in Newark
• NDT Server in Camden

INTERPRETING THE RESULTS

After a test run completes, NDT presents a summary of the observed traffic rate between the client and the server, and will any highlight notable exceptions. If the test indicates a network problem, the problem should be corrected before further testing is performed. A "good" throughput result may still be substantially less than the line rate of the slowest link in the network path between the client and the server, as it may be limited by competing traffic, the client's network interface card, network drivers, TCP stack parameters, or any combination of the above. The table below characterizes typical results for a modern computer using the most up-to-date network device drivers.

Additional test run statistics are available by clicking the "Statistics" and "More Details..." buttons. The "Statistics" button presents information about the TCP connection between the client and the server, and presents analysis of the prior test run. The display may also present information about where performance bottlenecks may have occurred.

The "More Details..." button presents the raw values of the Web100 kernel variables on the test server for the prior test run. The report also presents the theoretical maximum throughput for the current TCP stack configuration. The theoretical maximum throughput may exceed the host's link speed. This is normal, and demonstrates how the host's TCP stack may limit the effective network throughput.

Please take note of the following when tuning TCP stack parameters:

1. Requires a thorough understanding of the tunable TCP parameters before modifying anything, and
2. Requires knowledge of fundamental characteristics of the network path before modifying TCP settings, as optimal settings for a LAN environment may be poorly optimized for Internet performance, and vice versa.