Show pagesourceOld revisionsBacklinksBack to top × Table of Contents SQM (Smart Queue Management) Preparation: Measure Your Current Speed and Latency Configuring SQM Results A Little More SQM Tuning SQM (Smart Queue Management) OpenWrt has a package called SQM used for mitigating bufferbloat - the undesirable latency that arises when the router buffers too much data. Bufferbloat is most evident when the link is heavily loaded with downloads or uploads, and causes increased latency, or ping. It causes poor performance for VoIP and video chat, online games to lag, and generally makes people say, “the Internet is not responsive.” This lag is mitigated using SQM and a small trade-off to peak throughput. SQM is heavily CPU-based. Slower devices may not be able to keep up with your connection speed. Install and enable the luci-app-sqm package (or sqm-scripts if you don't use LuCI) to mitigate this bufferbloat. See also: SQM configuration file. Preparation: Measure Your Current Speed and Latency Before you can optimize your network, you need to know its current state. When your network is quiet, run a speed test to find your down/upload link speeds: Run the DSLreports Speedtest. You will use this information in configuration. (Optional: consider Recommended Settings Guide to get the most out of the DSLReports.) An alternative to the DSLReports is Waveform's Bufferbloat Test. (The biggest relevant difference between WaveForm and DSLReports is that Waveform uses HTTP requests over WebSockets and CloudFlare's CDN which should be closer to most end-users.) If you are using this OpenWrt device as an Extender, Repeater or Bridge, test the bufferbloat of your upstream network device (OpenWrt or otherwise) and determine if an issue is present there first. Configuring SQM To enable and configure SQM in LuCI go to Network → SQM QoS. The default values will work well, however you can improve performance further by setting values specific to your internet connection described below: 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 In the Queue Discipline tab: Choose cake as the Queueing Discipline (or fq_codel, consider note 2) Choose piece_of_cake.qos as the Queue Setup Script Advanced Configuration may be left unchecked In the Link Layer Adaptation tab, select your link type (optional: set mpu see note 3): For VDSL - Choose Ethernet, and set overhead 34 (or 26 if you know you are not using PPPoE) (mpu 68). If the access link uses 100Mbps ethernet, set overhead 42 (mpu 84). 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). If you set the shaper rate to > 760 Mbps, set overhead 42 (mpu 84), because now 1 Gbps ethernet between modem and router affects the worst-case per-packet-overhead. For Ethernet or Fiber to the premises - Choose Ethernet, and set overhead 44 (mpu 84) If unsure, it's better to overestimate - Choose overhead 44 (mpu 96) Click Save & Apply. That's it! You can confirm mitigation of bufferbloat by re-running the speedtest. Any increased ping during download/uploads will now be minimal. Results As an example, the user below is running OpenWrt with kernel 5.15 on a WRT32X router. The internet is a DOCSIS 3.0 cable modem with 300/20 Mbit service. Note this ISP is including ~15% over-provisioning on downloads. Speedtests were run before and after enabling SQM. SQM Cake was enabled with 90% dl/ul limits of baseline speedtest values. Increased latency under load has dropped to zero, and lower pings with no packet loss is observed during VoIP and online gaming during heavy internet usage on the network. Link to user's speedtest results. Bufferbloat Results (before and after SQM) QoS Download Upload Unloaded Ping DL Latency UL Latency Quality grade Bufferbloat grade None 345 Mbits 20 Mbits 12 ms +22 ms +31 ms B B SQM 312 Mbits 18 Mbits 12 ms +0 ms +0 ms A+ A+ A Little More SQM Tuning 1. The steps above will handle latency well with 85-95% limits being a great starting point. But you can often improve speed and latency further via a couple experiments to adjust the settings with these steps: Increase the Download speed limit and retest until latency begins to increase, then go back to a slightly lower value. Repeat the same for the Upload speed. Use DSLReports Speedtest and/or Waveform's Blufferbloat test to achieve A+ quality and A+ bufferbloat grades when the optimal settings are found. 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 DOCSIS cable, use a speed test that runs for a longer time. Some cable providers trick speed tests by adding an extra 10-15% over-provisioning only for the first 10 seconds (so speed tests look better!). 2. Cake is often the preferred algorithm as it is robust and efficient in mitigating bufferbloat. However, the consensus is that while cake bundles many features for a typical internet access link, fq_codel is the faster, albeit less comprehensive option. One user found fq_codel gave about 15% higher throughput when CPU limited and this email thread showed similar results. 3. To set your link mpu (read SQM Details and SQM setting question) for efficiency improvements. Setting mpu will ensure rate shaping is correct for the smallest packets. 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 6. To reach A+ score in Waveform's Blufferbloat test, it is required to disable Software and Hardware offload - read post 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.OKMore information about cookies Last modified: 2023/06/22 05:45by dpawlik