Network testing and troubleshooting can be complicated, but it doesn't have to be if you have the right tools. One tool that we recommend at CNET Labs is Qcheck, a free software utility available from IXIA. CNET Labs uses IXIA's IxChariot for some of its network testing, and the same endpoint architecture that is built into IxChariot is also a part of Qcheck. In fact, Qcheck and IxChariot share the same endpoint software. You can run throughput and response time tests with Qcheck that should yield results comparable to those of our tests at CNET Labs. If you are considering an upgrade and would like to know how your current networking solution stacks up against the newest technologies, test your network using Qcheck, and compare your results with CNET Labs' performance tests.

How Qcheck works

Qcheck consists of two components: a console that allows you to initiate and monitor performance tests, and a performance endpoint that runs in the background on each system in the test. The console is used to instruct the first endpoint of an endpoint pair to execute a particular test. Upon completion of the test run, endpoint 1 passes the result back to the console, which displays the result. You can export a detailed record of the test to an HTML document. Qcheck is capable of running several different kinds of tests, including throughput, response time, and streaming. It can also help you check traffic patterns via traceroute.

Installation

To run a Qcheck throughput test, you will need to download and install the Qcheck console. To use Qcheck, you also need IXIA's Performance Endpoint software installed on each networked computer you intend to test. As part of the installation process, the endpoint for Windows operating systems are automatically installed on the computer where you installed Qcheck. Additional endpoints for other operating systems can be downloaded from IXIA's site. Both the endpoint and the console are free downloads. The console runs only on Windows operating systems; however the endpoints run on a wide variety of platforms. This means you can use Qcheck to test networks consisting of machines running Windows, Mac, and Linux operating systems as long as one of the machines is running Windows for the console.

Qcheck and Firewalls

If you have a firewall filtering traffic on your network, you may have to take certain steps to get Qcheck to successfully run tests between endpoints. Software firewalls located on any of the systems running the console or endpoints can prevent Qcheck tests from completing. Qcheck uses fixed port numbers to communicate with the endpoints, making it is easy to configure your firewall to allow Qcheck's data through. Theses ports are referenced in the Qcheck user guide.

Running a throughput test

After you have installed the console and the performance endpoints on networked machines, you are ready to test your network. Enter the IP addresses of the two machines on your network that you would like to test in the endpoint boxes at the top of the console's graphical user interface. The boxes are labeled "From Endpoint 1" and "To Endpoint 2." If you don't know the IP address of a Windows machine you would like to include in the test, open a command prompt on that machine and enter ipconfig. This calls up IP address information for that machine. A cluster of radio buttons in the center of the console allows you to select the network protocol and type of test you would like to run.

Select TCP as your protocol and Throughput as the test you would like to perform. You can also enter the number of iterations of the test you've selected and the data size to be transferred between end points. The default settings are appropriate for most home network scenarios, but on fast networks, such as 100Mbps Ethernet, you may find that you need to increase the data size in order to get a reliable timing result. Increasing the default value by a multiple of 10 will generally do the trick. In the test described here, this would change the data size from 100 bytes to 1,000 bytes, but you can increase the data size up to 32,000 bytes. Larger data sizes increase the duration of the test.

Once you have selected your endpoints and chosen your test and protocol, you can begin a test by clicking the Run button at the bottom of the console. At this point, the console forwards your test instructions to endpoint 1, which extracts its instructions, sending the necessary test information to endpoint 2, and begins the test. During the test run, endpoint 1 collects the results and forwards that information to the console. The results appear in a dialog box at the bottom of the console. You can get more detailed information, including a log of your test configuration, by clicking the Details button to the right of the Run button. Run the test a few times to make sure that the results are consistent and accurate.

Next, select the UDP protocol and run the test again. Use the average of the TCP and UDP results to compare the throughput of your own network with CNET Labs' performance results. You may want to try running the test both in the absence of additional network traffic and during a simulated high-traffic situation with multiple simultaneous downloads. This will give you an idea of the degree to which your network is able to bear heavy traffic loads.

Interpreting throughput measurements

You may have noticed that vendors of networking products typically advertise throughput speeds that are substantially more than the data-transfer speeds you experience at home or read about in CNET's reviews. This is because vendors use theoretical throughput ratings that include the sum total of data transferred across the network under optimal conditions. The sum total of data in a file transfer is always more than the data that makes up the file.

When you transfer a file from one computer to another, the data is broken up into packets, each of which includes not only the data of the file you are transferring, also called payload data, but also data associated with connection setup, packet headers, trailers, flow control, and packet retransmissions. In some ways, a data packet is like a letter you send through the postal system. In addition to the letter, you also send the envelope and the information on the envelope. But the letter analogy applies only to packets containing payload data. Some of the packets sent in the course of a file transfer don't include any payload data at all and are more like envelopes without letters. For example, a packet may be involved in sending information associated with more technical aspects of the file transfer, such as connection maintenance. All of the data sent over the network that is not payload data is referred to as protocol overhead. When the manufacturer of an 802.11g system claims it offers 54Mbps throughput, it's projecting the sum total of bits that the network is capable of transferring under optimal conditions, including all of the protocol overhead.

At CNET Labs, we filter the protocol overhead out of our performance tests and report the throughput in terms of the payload data only. In many cases, the actual payload throughput at the application layer is often substantially lower than the total data throughput through the entire protocol stack. Payload throughput offers a much more realistic reflection of the speed of the network as you experience it. Qcheck's throughput test delivers this information as well, so it offers an ideal comparison to CNET Labs' tests. In the case of some networking products, the actual payload throughput can be less than 50 percent of the bandwidth advertised by the manufacturer.

Testing response time

Throughput is the most relevant indicator of performance for large file transfers, but another useful performance indicator for a network is response time, which refers to the amount of time it takes to send a request and receive a response over a network. Qcheck allows you to capture highly accurate response-time measurements because it uses the same protocols used by most applications--namely, TCP and UDP.

Another common tool for measuring response time is ping. If you haven't already tried ping, you can do so on any Windows or Unix/Linux system (including Mac OS X systems) by opening a command prompt or a console and typing ping followed by a space and the IP address of any connected system. If you're not connected to a network, you can use the IP address of your local machine. Ping sends out a series of requests and displays the time of each response. But ping doesn't use TCP or UDP to measure response time. It uses Internet Control Management Protocol (ICMP). The problem with using ICMP to measure response time is that this protocol is rarely used by TCP/IP applications, so the test is a bit artificial and can lead to inaccurate results. Across a small network, the difference in response time between ICMP and TCP may be negligible, but in some cases, the gap could be significant. ICMP packets are smaller than TCP and UDP packets, so depending on the configuration of your networking equipment, ICMP and TCP may be handled differently by connecting devices such as routers.

Running response tests using TCP or UDP gives you the opportunity to collect highly reliable measurements that yield results more in line with those of real-world applications and actual network use. The parameters you can manipulate for a Qcheck response time test are Protocol, Data Size, and the number of test Iterations. Another advantage to Qcheck is that it allows you to measure response time remotely from the console between any two endpoints on the network, whereas ping is executed from the local machine.

Running traceroute and streaming tests

You can do much more with a network than share files and printers. With the right equipment, you can build a network that can sustain real-time streaming media applications such as games, Voice Over IP, or video broadcasts.

One of the requirements for successful streaming is a minimum of latency on the network. Latency is the amount of time it takes for a packet to reach its destination after it is sent, and it increases when you have a bottleneck on your network--for example, a hub that is regularly pounded by heavy traffic on multiple ports or an access point operating at a low connection speed that is slow to process information. Dividing a connection's response time by two generally gives you a good idea of the latency, assuming the response retraces the path of the request, but this is not always the case. If the paths of the request and response differ, they may have a different latency, and you may need to consider options for reducing the latency of the slow path or of redirecting the transmission to the faster path.

For streaming applications, data must be delivered quickly and reliably. If data is lost, you may experience a break in the stream, generally in the form of choppy video or poor sound quality. Qcheck's streaming tests measure the amount of lost data between endpoints. You can determine the actual path of a stream with Qcheck's traceroute tool, which shows you the number and order of hops a packet takes across the network, the round-trip time to each hop in the series, and the node name of each hop. Together, Qcheck's streaming test and traceroute features can help you diagnose and find solutions for latency-related network problems.

The right choice

Qcheck lets you examine the performance of your own network in a variety of ways and with a number of different protocols. It has a graphical user interface that is extremely easy to use, and it can tell you a lot about the condition of your network. More detailed information on Qcheck is available in a white paper by Jeffrey T. Hicks and John Q. Walker. Whether you are trying to troubleshoot a problem or just want to compare your own network throughput with CNET Labs' results for the latest networking solutions, Qcheck is the right choice for throughput and response-time testing on your network.