SQM (Smart Queue Management)

OpenWrt has a pre-built package for controlling Bufferbloat - the undesirable latency that arises when the router buffers too much data. OpenWrt calls the package Smart Queue Management (SQM), although it's also called active queue management (AQM).

Bufferbloat is most evident when the link is heavily loaded. It causes bad performance for voice and video conversations, causes online games to lag, and generally makes people say, “The Internet is slow today.”

The “luci-app-sqm” package of OpenWrt solves the problem of Bufferbloat. After a three-minute installation and configuration, you'll have a much more lively network connection. Here's how:

TL;DR Video guide: https://www.youtube.com/watch?v=FvYhifdQ92Q

Advanced SQM tuning guide: https://www.bufferbloat.net/projects/bloat/wiki/Getting_SQM_Running_Right/

Before you can optimize your network, you need to know its current state. Run a speed test to find your down/upload link speeds. To do this:

• When your network is relatively quiet, use DSLReports Speedtest at: http://www.dslreports.com/speedtest You will need this information in the next step. (See https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803 for how to get the most out of the DSLReports Speedtest)
• A decent alternative to the dslreports test that also helps to asses bufferbloat is waveform's bufferbloat test https://www.waveform.com/tools/bufferbloat; while you are running that test, waiting for the results, their “Frequently Asked Questions” section is worth reading… the biggest relevant difference to the dslreports test is waveform uses traffic sources and sinks in cloudfare's CDN which should be closer to most end-users.
• This is probably a good time to back up your configuration. (Optional, but always a good idea.)

The default values quite well for most situations. They represent conservative estimates which is generally desirable compared to under-estimating. You may be able to improve performance further by experimenting, see A little more SQM tuning below.

To configure SQM, choose Network → SQM QoS to see the Smart Queue Management (SQM) GUI.

1. In the Basic Settings tab:
   • Check the Enable box
   • Set the Interface name to your wide area network (WAN) link. Interfaces are listed in the dropdown, or check Network → Interfaces to find the name for the WAN port.
   • Set the Download and Upload speeds to 80-95% of the speed you measured in Preparation
2. In the Queue Discipline tab, you can leave the default settings or set the following:
   • Choose cake as the Queueing Discipline
   • Choose piece_of_cake.qos as the Queue Setup Script
   • The Advanced Configuration defaults are designed to work well out of the box.
3. In the Link Layer Adaptation tab, choose the kind of link you have (optional, default may also be used):
   • For VDSL - Choose Ethernet, and set per packet overhead 34 (or 26 if you know you are not using PPPoE)
   • For DSL of any other type - Choose ATM, and set per packet overhead 44
   • For Cable - Choose Ethernet, and set per packet overhead 18 mpu 64 noatm
   • For true ethernet or Fiber to the Premises - Choose Ethernet, and set per packet overhead 44
   • When in Doubt, it's better to overestimate - Choose packet overhead 44
4. Click Save & Apply. That's it!

Measure your latency again with the speed test. You should notice that the measured ping times should only be slightly larger during the downloads and uploads. DSLReports should now report A+ ratings for Bufferbloat and Quality. Try VoIP, Skype, Facetime, gaming, DNS, or general web browsing. They will be much more pleasant even if someone's uploading or downloading a lot of data.

You've reduced your connection's bufferbloat!

The steps above will control latency well without additional effort. The 80-95% range mentioned above is a good starting point, but you can often gain more speed while still controlling latency by making a couple experiments to adjust the settings.

If you want to spend a few more minutes tuning, do these steps.

• Increase the Download speed until the latency begins to increase, then go back to a slightly lower value.
• Do the same for the Upload speed entry.
• It may be worth your time to tweak the two a bit up and down to find a sweet spot for your connection and usage.
• We recommend you use DSLReports Speed Test for the latency tests because it measures both speed and latency at the same time.

Note 1: If you have a DSL link, the experiments above may produce Download and Upload values that are actually higher than the original speed test results. This is OK: the ATM framing bytes of a DSL link add an average of 9% overhead, and these settings simply tell SQM how to make up for that overhead.

Note 2: If you use a cable modem, you should use a speed test that runs for a longer time. Cable modem makers have tricked speed tests by using “speedboost”, which can provide an extra 10 Mbits or so for the first 10 seconds (so the speed test will look good(!)). Don't be surprised if the “right” setting for your queue rates is lower than the no-SQM speed test results. You may need to tune the speeds down from your initial settings to get the latency to the point you need for your own usage of your connection.

Note 3: You can also experiment with the other settings (read SQM - The Details for more information), but they will not make nearly as large a difference as ensuring that the Download and Upload speeds are maximized.

Note 4: Check the FAQ and Troubleshooting SQM guides.

Note 5: Why Cake is typically the preferred algorithm https://www.bufferbloat.net/projects/codel/wiki/Cake/ as it is more CPU and RAM efficient than fq_codel. Or at least it was early in its development, currently the argument is more that cake bundles almost all features that are helpful for a typical private internet access link.

Note 6: Read more about Cake tuning on the man page including link layer adaptation settings: https://man7.org/linux/man-pages/man8/tc-cake.8.html