Manual leg tuning

Bond performance depends on having accurate leg speeds. In particular, Quality of Service and the IDMPQ packet distribution algorithm perform poorly when leg speeds are set too high.

Legs should be configured so that packets are held in a queue on the aggregator or bonder rather than in the modem or ISP router, where the size of the queue is unknown. Correct tuning of each leg will result in the highest, most stable speeds through the bond. Tuning leg speeds should be done as part of the bond performance tuning procedure.

To tune a leg, follow these steps:

  1. Run a single TCP download test on the leg. Leave the rate limit field blank. Set the length to 60 seconds, to verify whether or not the leg offers a “boost” feature that increases speed

    at the beginning of a transfer.

    image0

    If the leg offers a boost feature, the throughput chart will show a

    higher speed for the initial part of the test. For example:

    image1

    If it known that the leg does not offer a boost feature, the test length can be left at the default, 10 seconds.

  2. Review the test result. Find the overall throughput in Mbps.

    image2

    If the leg offers a boost feature, the average throughput value will reflect the higher initial speeds. In this case, use the throughput chart to identify the speed that the leg offers after the boost ends. If the throughput chart shows a lot of variation in the speed during the test, consider repeating the speed test with a concurrency of 4 or 8.

    image3

    This enables a technique that improves the consistency of test results so that the leg bandwidth can be determined accurately. If the concurrency needs to be set above 1 to achieve stable speeds for any individual leg in the bond, it’s likely that the TCP proxy will need to be used to get good speeds through the bonded connection.

  3. Use the throughput result from the test above to choose rate limits for further testing. Run a set of TCP download tests at 0.1 Mbps (100 Kbps) intervals from about 20% below to 20% above the tested throughput. Use the same concurrency setting as you used to get stable speeds in the non-rate-limited test. For example, if the throughput from the non-rate-limited test was 2.5 Mbps, run tests with the rate limit set to 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, and 2.9 Mbps.

    image4

  4. Compare the rate-limited set of tests to determine the limit that maximizes throughput while still achieving low a latency. For example, if a download test limited to 2.5 Mbps resulted in 25 ms latency and a test at 2.6 Mbps resulted in 120 ms latency, then 2.5 Mbps is the optimum speed.

    image5

    Identify the rate limit at which the latency increases.

    image6

    This chart shows that when the rate limit (the values along the x-axis) reaches 2.6 Mbps, the latency increases dramatically, from 20 ms to about 160 ms. The highest rate limit that still keeps latency low is 2.5 Mbps. Note that the overall throughput (the dark blue line) doesn’t increase at all for rate limits above 2.5 Mbps, which means that setting the rate limit to 2.5 Mbps doesn’t leave any unused bandwidth on the leg. Even if the rate limit is set to 2.6 or 2.7 Mbps, the overall throughput doesn’t increase compared to setting the rate limit to 2.5 Mbps.

  5. Optional: run more precise tests separated by 0.05 Mbps (50 Kbps) or 0.02 Mbps (20 Kbps) near the optimum rate limit identified in (4). For example, if a rate limit of 2.5 resulted in 25 ms latency and 2.6 Mbps resulted in 120 ms latency, a more accurate optimal speed could be identified after running tests at 2.52, 2.54, 2.56, and 2.58 Mbps. This minimizes the unused bandwidth of the leg.

    image7

  6. On the bond edit page, set the download speed of the leg to the optimum value.

    image8

  7. Repeat steps 1-5 to set the upload speed.