Technical description of the Network Performance Test

This page contains a technical description of the inner workings of the network performance testing tool. It may be of interest to advanced network administrators or the curious; however, it is not required that you read or understand this page to take the test or interpret its results.

Test stages

The test is performed in several stages:

TCP throughput test
HTTP throughput test
Packet dump extraction

In the TCP throughput stage, raw TCP performance is measured over one or more TCP streams (socket connections). The results of this test should be a reasonable indicator of network layer performance.

In the HTTP throughput test, a sample file (filled with random content) is downloaded over HTTP and discarded. This gives a more realistic test of performance when using actual CADC applications, and usually differs from the TCP throughput test with a lower result. This test only uses a single stream.

In the packet dump extraction stage, the test server looks through a ring buffer of recorded network traffic and extracts the portion associated with your test. It inserts this captured traffic into a database, from which it can be downloaded.

TCP throughput

The goal of the TCP throughput stage is to measure raw TCP network performance. TCP is the network protocol of choice for reliably transmitting content across the Internet, as it provides for reliable delivery (each sent packet is acknowledged by the recipient) and in-order delivery (the recipient receives data in the order it was sent). However, TCP also suffers from performance issues on lossy or congested networks, or from Operating Systems that are not properly configured. Under some of these conditions, performance increases may be seen when more than one stream is aggregated, and the throughput of a single stream does not represent the available capacity of the network.

Multiple TCP streams

Many throughput tests only measure the performance of a single stream. Our test incrementally opens multiple streams to better determine aailable network capacity.

The test begins with one control stream and one data stream. The control stream is a channel that allows for communication between the client and server applications. The data stream has a tight loop on the server side that continuously sends traffic over the socket, while the client side has a tight loop that drains the socket buffer. Both the client and server side applications utilize one thread per socket.

The test maintains one data stream for a period of about 10 seconds. It is over this duration that the packet capture data comes from. After this initial duration has elapsed, it opens another data stream and waits for the throughput to stabilize.

After each connection has been allowed to stabilize, the application measures aggregate throughput (the sum of each stream's individual throughput) and reports it to the server. The application will continue to open more data streams while doing so increases the aggregate throughput, or until it reaches a preset maximum number. Once it has reached the maximum number of streams or once opening streams causes a decrease in aggregate throughput, the TCP portion of the test will stop.

The data that is recorded from this portion of the test consists of:

Client IP address
Maximum aggregate throughput (bytes/second)
Number of streams to achieve maximum aggregate throughput
Packet capture data from the initial duration of the test

HTTP throughput

The goal of the HTTP throughput stage is to measure a real world CADC data transfer. HTTP is the protocol, layered on top of TCP, that World Wide Web applications use to communicate with web servers.

After the completion of the TCP test, if a HTTP test has been selected, the application will enter the HTTP test stage. During the HTTP stage one of three data files is downloaded from the CADC web servers, depending on your size selection:

This file is not written anywhere to disk. There is a tight loop on the end of the socket to empty the buffer. The throughput is measured as the total bytes transferred over the total elapsed time.

The data that is recorded from this portion of the test consists of:

HTTP throughput (bytes/second)
File downloaded

Packet dump extraction

After the TCP throughput test is completed a packet dump of the initial, single stream, portion of the test is extracted and placed into a database for download.

To facilitate this, the test server runs an instance of tcpdump recording test related traffic into a large ring buffer. Once the test has completed, and if a dump has been requested (the default setting), the server will look through this ring buffer and pull out the initial portion of your test traffic. This will be inserted into a database for storage. Once other tests are performed, old test traffic in the ring buffer will be overwritten.

This extraction is performed completely server side, and so the packet dump provided is the traffic as seen by the server, which can provide invaluable insight into network problems that are not visible from the client.

The data that is recorded from this portion of the test consists of:

Traffic from the single stream portion of your TCP throughput test.