Home Gateway: Unitary LAN Ethernet tests

The LAN-LAN performance is one of the primary performance parameters of a Home Gateway. This test will verify the throughput and latency for different LAN and LAN configurations, both in function of the frame size.

First, the maximum throughput performance is determined. This is done in one direction only.

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 WAN interface is not used.

The LAN interfaces must be configured this way:

• a fixed single IP address (192.168.1.1/24)
• full duplex, auto-negotiation

By default, the UDP destination port is configured to be port 20005.

The ByteBlower project exists out of many flows and scenarios, generated by using the throughput wizard multiple times. Some tweaks were needed to make the different frames unique.

To execute a test, the user can run the 'estimate' batch, which runs a test at different speeds for the four different frame sizes. It will generate a report for each frame size. Those reports can then be used to create a fine-tuned batch with the right scenario for each frame size. The estimate batch will generate a report like this for each frame size:

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:
Wizard > Generic > Throughput

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 finetuning. 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:

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.