Dear Readers!

Today I’m sharing some quick thoughts on OpenWRT’s builtin Active Queue Management (AQM) facilities, which they also call as Smart Queue Management (SQM). As it turns out, this feature is intended to decrease bufferbloat, a phenomenon, that can cause “high latency in packet-switched networks by excess buffering of packets” and “packet delay variation (also known as jitter), as well as reduce the overall network throughput”, as stated by the corresponding wikipedia page. According to OpenWRT’s own manual page on the subject, “In a three-minute installation and configuration, you’ll have a much more lively network connection”. Well, I was intrigued by this, as who doesn’t want to have a better connection with only a cost of a meager three-minute procedure. So, I followed the instructions to improve my home network.

As per step one, I ran a speedtest, or actually two, using two different services ( for A series and for B series. See image captions).

woSQMMeasurement 1A, without SQM

woSQMMeasurement 1B, without SQM

Everything is as expected, nothing out of the ordinary. The provider delivers on his promises. I then followed the guide and set up SQM, which also involves setting up- and download speeds as arguments to some parameters among others. Initially I set them to the actual speeds measured as seen on the images above, and the results I got weren’t entirely as anticipated. Although I got now an ‘A’ grade for BufferBloat on dslreports, my down- and upload speeds suffered a lot: they dropped to 82.4 and 28.9 Mbit/s, respecitvely. I was surprised big time, as I didn’t expect that these settings would affect my actual rates so much.

To stop fooling around, the second time I used arguments in the recommended region (80-95% of actual speed) as parameters for the SQM, namely 85% for both up- and downlink. For some interesting reason, the speeds increased a bit to 86/32.2 Mbit/s, though I expected them to decrease (this is what the user guide suggests). Also, if we examine the speed plot, we also see that the down speed is quite erratic if compared to the original, which was mostly smooth after the initial few seconds. Here’s a screenshot of the 85% setting:

woSQMMeasurement 3A, with SQM. Speed is set to 85% of actual.

woSQMMeasurement 3B, with SQM. Speed is set to 85% of actual.

I still wasn’t impressed by these results, so I bumped up the arguments to be 90% of actual speeds, and this time I got a 86.3/32.3 Mbit/s connection. Interestingly, when I used as a control measurement, the speeds were somewhat higher, but not as high as the originals. This might be due to the fact that uses measurement servers that are closest to the to be measured connection. Pings also reflected this difference, as while mostly gave me 22ms latencies, results always stayed in the 5-6ms region.

Finally, just to be on the safe side, I turned the whole SQM thing off and did a dual measurement again:

woSQMMeasurement 5A, SQM turned off again.

woSQMMeasurement 5B, SQM turned off again.

As it is evident, the speeds returned to their orignal values, so we can safely say that SQM has quite the negative impact on your max speeds.

Here’s a plot of all the download speeds, followed by a tabulation of all data:

woSQMMeasured download speeds for all SQM settings (off, 100%, 85%, 90%, off).

woSQMData of all measurements, including pings and grades.

At the end it can be concluded, that despite SQM decreases BufferBloat (B column in tabulation), it has severe adverse effects on the maximal achievable throughput and stability. The normal ping on the other hand doesn’t seem to be affected in any way by SQM, so I really wonder about the usefulness of SQM, for small home networks at least. Maybe I didn’t play enough with the settings, but I think I more than exhausted the “three minutes” the official OpenWRT page suggested, so I’m giving up on SQM right now. I’m not saying that it is useless, as on larger networks the benefits might be far more conspicuous (and the adverse effects might be less striking) than they are here, so I’m filing SQM under “might be usable under certian circumstances” for the time being. All in all, it doesn’t seem that it is worth bothering with it on small home networks, unless some special timing requirements are in place, or the decrease of bufferbloat is far more important than raw throughput.

As always, thanks for reading.