Running a speed test

To run a speed test, complete the form and click Test. Tests for a bond are run one at a time. You can start a test while a test is already running, and the second test will start automatically when the first test finishes.

Speed tests from within the management server do not use the TCP proxy, even if the TCP proxy is enabled. If you proxy ports between 32768 and 61000, TCP speed tests may not work at all.

Running a speedtest from the management server imposes higher-than-usual strain on the node CPU, and can affect results when nodes are performing near the limitations of their hardware.

Tests are run using the network functions of the bonding hosts, which run Linux. Some operating systems, especially Windows XP, perform worse than Linux under certain bonding configurations. If a customer reports poor speeds even though these speed tests return good results, it may be necessary to run tests manually with the same operating system used by the customer. The TCP proxy may help significantly with this situation.

Test options

Speed tests have the following options:

Target

The object to test. Selecting the name of the bond runs a test over all the legs in the bond, just as a customer would do if they were to test from inside their network. Selecting the name of a leg runs a test over that leg. Only legs in the active, up state can be tested.

Bond tests use the current configuration of the bond, including packet distribution algorithm, compression, reorder max-hold value, and leg upload and download speeds. During a bond test, customer traffic is dropped.

During a bond test, customer traffic is dropped.

Leg tests do not use the bond’s configuration. Test data is not compressed or reordered, and the configured upload and download speeds of the leg are ignored. During a leg test, customer traffic is routed through the legs not under test and traffic shaping is disabled.

Protocol

The test protocol. TCP, the most common protocol used on the Internet, can be used to test speeds on healthy bonds and legs and to identify packet reordering and other performance issues. UDP can be used to test speeds on bonds and legs with reordering and stability issues and to identify packet loss.

Direction

The test direction from the bonder’s perspective.

Rate limit

The sending rate limit of the test, in Mbps. Rate limits apply to leg tests but not bond tests. This field can be given a few different values:

1. An empty value, to send as fast as possible.
2. A single number, to send no faster than that value in Mbps.
3. A set of numbers separated by commas. For example, “2.4,2.5,2.6”. This value would run three tests, identical except for the rate limits.

With no rate limit, data is transmitted as fast as possible and is throttled by the modem or ISP router. With a rate limit in place, traffic is throttled at the sending host before it gets to the ISP. If the test rate limit is higher than the speed of the target leg (for example, testing a 3 Mbps DSL leg with a rate limit of 5 Mbps), it will be throttled at the modem or ISP router.

Length

The length of the test, in seconds.

Concurrency

The number of TCP flows to use for the test. This can be used to simulate multiple transfers occurring through the bond at the same time. When testing a bond, a large difference in throughput when testing with different concurrency levels indicates a problem with packet distribution and reordering. Ideally, a bond or leg test should achieve the same throughput when the concurrency is one as when it is 8 or 16.

Concurrency is not applicable for UDP tests.

Payload size

The size of the packet payload in UDP tests. This can be used to test performance and packet loss at different packet sizes as well as to confirm delivery of packets at the size of the tunnel MTU.

The maximum payload size is the tunnel MTU, shown on the bond details page, minus 28 bytes for IP and UDP headers. If you use a size greater than this, or if the real MTU of a leg is less than what the bonder thinks it is, you will see a larger-than-expected level of packet loss or the error message, “Test slave received no data from master for 5.0 seconds.”

Payload size is not applicable for TCP tests.

Preset tests

You can quickly run a standard test by clicking one of the links in the Preset Tests section.

Repeating a test

To repeat a test, click the icon beside the test in the test result list, or click the Repeat button on the test details page.