Home Gateway: Unitary WAN Ethernet tests
| Introduction | The WAN-LAN performance is one of the primary performance parameters of a Home Gateway. This test will verify the throughput and latency for different WAN and LAN configurations, both in function of the frame size. First, the maximum throughput performance is determined. This is done for both directions (up and downs) separately. A combination of upstream and downstream is not considered. |
| Test setup |
|
| Configuration | Each trial for each frame size has a duration of 1 minute. For the GUI project, we created different test scenarios with different loads for 4 different frame sizes: 66, 512, 1024, and 1518 bytes. For the Tcl script, we use our RFC2544 implementation to determine the maximum speed. When this speed is determined, we perform a latency measurement at that speed. The Home Gateway should be configured with the WAN interface:
The LAN interfaces must be configured this way:
By default, the UDP destination port is configured to be port 20005. |
| Execution | The test execution through the GUI is done in two phases: we first do a rough estimation. In the second stage, we perform a more fine-tuned test. We can continue this last step until we have a result that has the required resolution. In this example, we will use a 10Mbps precision. |
| Estimation | To perform an estimation, we can run the 'Estimate' batch from the example project. This will send traffic for each frame size (66, 512, 1024, and 1514) at 100Mbit up to 1Gbit, increasing with 100Mbit each iteration. It will generate a report for each frame size like this:
So, in this example, the forward performance of the Home Gateway for 512-byte frames is between 200 and 300 Mbps. We can now create a new batch that performs in the best range for each frame size in each direction. |
| Finetuning | Fine-tuning is done by creating a batch based on the result of the estimation. For our device under test, this batch looks like this:
We can run this test and we will have a report for each frame size, telling us about the best performance with 0% of loss, and the latency for such a test, like this:
This report shows the maximum downstream performance for 66byte frames is 40Mbps. At that point, the device will have an average latency of 522us and a jitter of 180us. |
| Implementation | The ByteBlower GUI allows the easy creation of scenarios running flows at different speeds. The GUI uses the throughput wizard for this purpose. This wizard can be found in the menu:
Through this wizard, you can create a scenario running a frame of a certain length at different rates. If we already have an idea of the performance of the device under test, we can directly start in that range and tune the minimum and maximum throughput that will be used. If we can, we can create a first scenario performing a throughput test at different rates which differ a lot, to have a first indication. Depending on the device under test, sending at a high speed and verifying the throughput also provides a good ballpoint throughput. Once we have a global idea of the throughput, we can use a second scenario for fine-tuning. We can repeat this wizard for different frame sizes and have different scenarios for each frame size. To run an automated test, we can then combine those scenarios in a batch:
|
| Latency | Because we are not only interested in the throughput but also the latency at maximum lossless speed, we want to run a latency test too. If you are on a ByteBlower 2100 or better, you can combine a throughput flow with a latency test. Older systems, such as the ByteBlower 1000 series will not be able to run a latency test at high speeds. In that case, a second flow can be added to the throughput test, running at low speed and performing the latency test. Because latency measurements overwrite the last 8 bytes of a frame, we must make sure that frames are different at a different location in the frame. The throughput wizard in GUI version 1.8.32 and later will generate good frames, older versions may generate a difference at the end of the frame. A second important note is that latency measurements can generate bad UDP checksums (see this KB). Our example project uses a UDP checksum of zero to work around this issue.
|
| NAPT | Because our Home Gateway will be performing address and port translation, we must make sure we configure our ports accordingly:
|
