Two ways to test network throughput using ByteBlower
The first step after installing a new network is often to determine its maximum throughput. At the DOCSIS 3.1 interop that we organized a couple of months ago, several participants stayed after to get the highest throughput on their modems. When new lab equipment is delivered to a customer, it’s much the same. In this post, I want to give a bit of back story on the throughput test that we’ve added to the 2.7.0 ByteBlower release. You’ll also get a sneak peek at what is coming in the next release.
For those not yet familiar with ByteBlower, there are two ways to generate a massive amount of network traffic. In the Frame Blasting mode, you can specify up front what frames should be sent and when they should be put onto the network, while the other option is to use the TCP network stack. The latter implements the same protocol as your operating system to get access to the internet. And, of course, you can mix both techniques at the same time.
TCP stack: popular and performant, but tricky
Of these two modes, the TCP stack is the most popular for getting throughput results. In contrast to Frame Blasting, you don’t need to specify how fast you’d like it to go. This makes it easy to get started. From there, it gets a little more complex. Most of the questions about TCP that we receive via support.byteblower@excentis.com are about which values to select for the best throughput. This is understandable, as there are more than 5 parameters to tune. We’re already planning on making this more intuitive in the next release.
Frame Blasting: an alternative throughput benchmark
The other option to generate network traffic with a ByteBlower is what we call Frame Blasting. In its least complex mode, this means sending out exactly the same packets over and over again at a fixed rate. If more data is blasted into the network than it can handle, traffic is lost. Ideally, only the excess amount is dropped, but in practice, often much more comes to standstill. Unlike TCP, Frame Blasting requires a little bit of extra logic.
Rather than doing the test a single time, repeat it as often as necessary, such as each time the frame rate is changed. If traffic was lost, the next attempt uses a lower value. If all data was received, go a bit bolder with a higher rate. An educated guess on the next frame rate helps reduce the total test time, but it doesn’t change the end result.
Logic based on best practice
The logic above isn’t difficult, nor is it new. It’s basically the same algorithm as those found in the ‘official’ reference text for throughput tests: RFC-2544. It’s successor, Y.1564, introduced some extra complexity, but essentially uses the same approach.
Compared to the first approach using TCP, this second algorithm takes longer to complete. However, the result is significantly more stable and easier to understand, as there’s no hocus-pocus going on behind the scenes. It’s worth noting that RFC 6349 does provide some good suggestions for throughput benchmarks with TCP – but that’s a topic to tackle in another post.
