=====================
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.

|image0|

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:

#. An empty value, to send as fast as possible.
#. A single number, to send no faster than that value in Mbps.
#. 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 |image1| icon beside the test in the test
result list, or click the Repeat button on the test details page.

|image2|


.. |image0| image:: /attachments/1179672/1343624.png
.. |image1| image:: /attachments/1179672/1343635.png
.. |image2| image:: /attachments/1179672/1343634.png
