News Categories
News
10 Gbit/s impairment node
Posted by Pieter Vandercammen on 29 April 2019 06:02 PM

A couple years ago we described our impairment node on our blog. We've used this system for functional tests of the ByteBlower server and verification of the latency measurements. This setup has served us well, performance was never a bottleneck. For a new experiment, part of an upcoming blogpost, our colleagues of the DOCIS testing services required a significantly faster impairment node. We were wondering how well this solution would scale up to 10Gbit/s. The answer, not as well as we've hoped for.

 
First, let's describe the impairment node for this experiment. Hardware-wise it's the same the chassis as the ByteBlower 3100. As those who have one running in their lab know, this system has a fairly modern CPU and provides 10G connectivity through an external NIC. The major difference with the ByteBlower is in the software. This impairment node ran a stock Ubuntu with almost no extra software, nearly all functionality was included in the live-cd. This made it very easy to get started.

The big challenge wasn't adding any delay but keeping it steady. The question is thus how well did our solution succeed in adding a constant delay?

To test this question we've used a ByteBlower 4100 to generate the network traffic. The impairment node bridged both interfaces of the 4100. The node was configured to add an extra millisecond of delay. As the results below show, this worked reasonably good at low frame rates. On all frame sizes, jitter was around 7 micro seconds.


With increasing throughput the sharp peaks did widen out considerably. In the graphs below we kept the same frame sizes but increased the frame-rate to 500 000 packets/second. These tests were thus done at 0.3 Gbit/s, 0.6 Gbit/s and 4.1 Gbit/s.



They illustrates clearly that the influence of the frame size is minimal. The additional jitter is caused by the overhead of packet processing.

The RFC-2544 results below confirm this too: the frame rate column stays fairly constant across all the frame sizes. It's only at 1500 bytes that the impairment gets close to the limits of the network card.



Comments (0)

We to help you!