SQM (Smart Queue Management)

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

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

The “luci-app-sqm” package (or “sqm-scripts” package if you don't have LuCI installed) solves the problem of Bufferbloat. After installation and configuration, you'll have a much more responsive network connection under load. Here's how:

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

Note: SQM is heavily CPU-based. Older or slower devices may not be able to keep up with your connection speed.

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:

The default values will work well and represent conservative estimates, which is desirable compared to under-estimating. You should be able to improve performance further by setting values below.

To configure SQM, go to Network → SQM QoS.

  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 85-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
    • Advanced Configuration may be left unchecked.
  3. In the Link Layer Adaptation tab, choose the kind of link you haven (to ensure rate shaping is correct also for the smallest packets one needs to also specify the correct mpu value):
    • For VDSL - Choose Ethernet, and set overhead 34 (or 26 if you know you are not using PPPoE) (mpu 68)
    • For DSL of any other type - Choose ATM, and set overhead 44 (mpu 96)
    • For DOCSIS Cable - Choose Ethernet, and set overhead 22 (mpu 64)
    • For true ethernet or Fiber to the Premises - Choose Ethernet, and set overhead 44 (mpu 84)
    • When in Doubt, it's better to overestimate - Choose overhead 44 (mpu 96)
  4. Click Save & Apply. That's it! (Please note the overhead values above are aiming at being generically useful and not at being as small as possible.)

Measure your latency again with the speed test. You should notice that the measured ping times are only slightly higher during the downloads and uploads. www.dslreports.com/speedtest should now report A+ ratings for Bufferbloat and Quality. Latency sensitive applications like VoIP, Skype, Facetime, gaming, or general web browsing will be much more consistent even if someone's uploading or downloading a lot of data.

You've reduced your connection's bufferbloat!

1. The steps above will control latency well. The 85-95% range mentioned above is a great starting point, but you can often improve speed and latency further via a couple experiments to adjust the settings. If you want to spend a few more minutes tuning, do these steps:

  • Increase the Download speed and retest until the latency begins to increase, then go back to a slightly lower value.
  • Repeat the same for the Upload speed.
  • 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 Speedtest and/or Waveform's Blufferbloat test for the tests and expect to achieve A/A+ ratings when optimal settings are found.

Notes: For DSL, 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. For a DOCSIS cable modem, use a speed test that runs for a longer time. Cable modem providers have tricked speed tests by using a “speedboost”, which can provide an extra 10 Mbits or so for the first 10 seconds (so the speed test will look better!).

2. Apply additional settings, such as your link mpu (read SQM Details and SQM setting question) for further improvements.

3. Cake is often the preferred algorithm https://www.bufferbloat.net/projects/codel/wiki/Cake/ as the shaped rate tends to be more CPU/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. One user found fq_codel gave about 10% more performance on a slow CPU.

4. Check the FAQ and Troubleshooting SQM guides for more information.

5. Consider Cake tuning parameters on the man page: https://man7.org/linux/man-pages/man8/tc-cake.8.html

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
  • Last modified: 2022/04/23 04:02
  • by tatami