Test it yourself:

Networks
By Allen Fear and Julie Rivera

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.

Running a throughput test

Click to enlarge.
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