| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision |
| docs:guide-user:network:traffic-shaping:sqm [2022/08/15 16:32] – [A Little More SQM Tuning] added email reference and cleanup language palebloodsky | docs:guide-user:network:traffic-shaping:sqm [2024/05/10 14:52] – remove a dead link, and small language tweaks palebloodsky |
|---|
| ====== SQM (Smart Queue Management) ====== | ====== SQM (Smart Queue Management) ====== |
| |
| OpenWrt has a package for controlling [[wp>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 [[wp>Active_queue_management|active queue management]] (AQM). | OpenWrt has a package called SQM for mitigating [[wp>bufferbloat]], the undesirable latency that arises when your router buffers too much data. |
| |
| 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." | Install ''[[:packages:pkgdata:luci-app-sqm|luci-app-sqm]]'' (or ''[[:packages:pkgdata:sqm-scripts|sqm-scripts]]'' if you don't use LuCI) and read below. |
| |
| 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: | ===== Overview ===== |
| |
| **TL;DR** Video guide (DSL example): [[https://www.youtube.com/watch?v=FvYhifdQ92Q]] | Bufferbloat is most evident when a connection is heavily loaded with downloads or uploads. It causes increased latency (ping), resulting in poor performance for realtime apps like VoIP, video chat, lag in online games, and generally makes the internet feel unresponsive. This can be mitigated with SQM. |
| |
| **Note**: SQM is heavily CPU-based. Older or slower devices [[https://forum.openwrt.org/t/so-you-have-500mbps-1gbps-fiber-and-need-a-router-read-this-first/90305|may not be able to keep up with your connection speed]]. | SQM is an integrated system that performs per-packet/per-flow network scheduling, active queue management (AQM), traffic shaping, rate limiting, and QoS prioritization. In comparison, “classic” AQM only manages queue length and “classic” QoS only does prioritization. |
| ===== Preparation: Measure Your Current Speed and Latency ===== | |
| |
| 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: | SQM is heavily CPU dependent. Slower devices may not be able to [[https://forum.openwrt.org/t/so-you-have-500mbps-1gbps-fiber-and-need-a-router-read-this-first/90305|keep up]] with your connection speed. |
| /* I removed the discussion of the very cool speedtest-netperf package because it's a distraction from getting SQM configured. We should advise readers simply to use DSLReports... - richb-hanover */ | |
| /* Seconding the above abandonment of the speedtest-netperf package. Seemingly affects latency results on low-spec routers due to CPU usage. Further, the opkg alternative is a python3 solution which is several MBs in dependencies. | |
| /* | |
| To install the //speedtest-netperf// package: | |
| * From LuCI web GUI: | |
| * choose **System -> Software**, then filter on the name **speedtest-net** and click the **Install..** button. | |
| * Or, from cmd: <code>opkg update && opkg install speedtest-netperf</code> | |
| |
| To use the script, ssh to the OpenWRT device and run the following (example results shown, additional options are available): | SQM is incompatible with software/hardware [[https://www.redhat.com/en/blog/should-i-offload-my-networking-hardware-look-hardware-offloading|flow offloading]] which bypasses part of the network stack. Be sure to uncheck those features in LuCI -> Firewall to use SQM. |
| <code> | |
| speedtest-netperf.sh -H netperf-west.bufferbloat.net -t 20 | |
| 2020-08-25 14:35:40 Starting speedtest for 20 seconds per transfer session. | |
| Measure speed to netperf-west.bufferbloat.net (IPv4) while pinging gstatic.com. | |
| Download and upload sessions are sequential, each with 5 simultaneous streams. | |
| ..................... | |
| Download: 805.68 Mbps | |
| Latency: [in msec, 21 pings, 0.00% packet loss] | |
| Min: 19.125 | |
| 10pct: 21.901 | |
| Median: 29.465 | |
| Avg: 31.586 | |
| 90pct: 36.378 | |
| Max: 63.253 | |
| CPU Load: [in % busy (avg +/- std dev) @ avg frequency, 18 samples] | |
| cpu0: 89.4 +/- 4.7 @ 1415 MHz | |
| cpu1: 31.3 +/- 2.7 @ 848 MHz | |
| Overhead: [in % used of total CPU available] | |
| netperf: 27.2 | |
| ..................... | |
| Upload: 600.61 Mbps | |
| Latency: [in msec, 21 pings, 0.00% packet loss] | |
| Min: 19.627 | |
| 10pct: 19.683 | |
| Median: 21.432 | |
| Avg: 21.521 | |
| 90pct: 22.424 | |
| Max: 26.307 | |
| CPU Load: [in % busy (avg +/- std dev) @ avg frequency, 19 samples] | |
| cpu0: 89.0 +/- 5.5 @ 1401 MHz | |
| cpu1: 33.5 +/- 4.0 @ 890 MHz | |
| Overhead: [in % used of total CPU available] | |
| netperf: 2.5 | |
| </code> | |
| */ | |
| * When your network is relatively quiet, use the [[http://www.dslreports.com/speedtest|DSLReports Speedtest]]. You will need this information in the next step. (See this [[https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803|Recommended Settings Guide]] to get the most out of the DSLReports speedtest.) | |
| * A decent alternative to the DSLReports test that also helps to assess bufferbloat is [[https://www.waveform.com/tools/bufferbloat|Waveform's Bufferbloat Test]]. (While you are running that test, browse their "Frequently Asked Questions" section... the biggest relevant difference between WaveForm and DSLReports is that Waveform uses HTTP requests over WebSockets and utilizes CloudFlare's CDN which should be closer to most end-users.) | |
| * If you are using this OpenWRT device as an [[docs:guide-user:network:wifi:relay_configuration|Extender, Repeater or Bridge]], please measure the bufferbloat of your upstream network device (OpenWRT or otherwise) and determine if an issue is present there first. | |
| * //This is probably a good time to [[docs:guide-user:troubleshooting:backup_restore|back up your configuration]]. (Optional, but always a good idea.)// | |
| ===== Configuring the SQM Bufferbloat Packages ===== | |
| |
| 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. | ===== Preparation: Measure Your Current Speed and Latency ===== |
| |
| To configure SQM, go to **Network -> SQM QoS**. | Before you can optimize your network, you need to know its current state. When your internet is quiet, run a speed test to find your peak download/upload speeds: |
| | * Run a speed test from [[https://www.waveform.com/tools/bufferbloat|Waveform]] or [[https://speedtest.net|Speedtest]]. Both display the latency during download and upload traffic, and grade your existing bufferbloat. |
| | * If you are using this OpenWrt device as an [[docs:guide-user:network:wifi:relay_configuration|Extender, Repeater, or Bridge]], test your upstream router (OpenWrt or otherwise) and determine if an issue is present there first. |
| | |
| | ===== Configuration ===== |
| | |
| | In LuCI go to **Network -> SQM QoS**. The default settings will work, however you can improve performance with settings specific to your internet connection as described below: |
| |
| - In the **Basic Settings** tab: | - In the **Basic Settings** tab: |
| * Check the **Enable** box | * 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 **Interface name** to your internet (WAN) link. Interfaces are listed in the dropdown, or check **Network -> Interfaces** to find the WAN port. |
| * Set the **Download** and **Upload** speeds to 85-95% of the speed you measured in Preparation | * Set the **Download** and **Upload** speeds to 90% of what you measured in Preparation |
| - In the **Queue Discipline** tab, you can leave the default settings or set the following: | - In the **Queue Discipline** tab: |
| * Choose //cake// as the Queueing Discipline | * Choose //cake// as the Queueing Discipline (or //fq_codel//, consider [[:docs:guide-user:network:traffic-shaping:sqm#a_little_more_sqm_tuning|note 2]]) |
| * Choose //piece_of_cake.qos// as the Queue Setup Script | * Choose //piece_of_cake.qos// as the Queue Setup Script |
| * Advanced Configuration may be left unchecked. | * Advanced Configuration may be left unchecked |
| - 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): | - In the **Link Layer Adaptation** tab, select your link type (optional: set mpu see [[:docs:guide-user:network:traffic-shaping:sqm#a_little_more_sqm_tuning|note 3]]): |
| * //For VDSL// - Choose **Ethernet**, and set overhead 34 (or 26 if you know you are not using PPPoE) (mpu 68) | * //For VDSL// - Choose **Ethernet**, and set overhead 34 (or 26 if you're not using PPPoE) (mpu 68). If the link uses 100 Mbps ethernet, set overhead 42 (mpu 84). |
| * //For DSL of any other type// - Choose **ATM**, and set overhead 44 (mpu 96) | * //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 DOCSIS Cable// - Choose **Ethernet**, and set overhead 22 (mpu 64). For rates > 760 Mbps, set overhead 42 (mpu 84), because 1 Gbps ethernet between modem and router affects the worst-case per-packet-overhead. |
| * //For true ethernet or Fiber to the Premises// - Choose **Ethernet**, and set overhead 44 (mpu 84) | * //For Ethernet or Fiber// - Choose **Ethernet**, and set overhead 44 (mpu 84). |
| * //When in Doubt, it's better to overestimate// - Choose overhead 44 (mpu 96) | * //If unsure, it's better to overestimate// - Choose overhead 44 (mpu 96). |
| - 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.) | - 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 23.05 on a [[toh:linksys:wrt_ac_series|WRT32X]] router. The internet connection is a DOCSIS cable modem with 500/35 Mbit service. Note this ISP includes over-provisioning. Cake was selected with 90% dl/ul limits on baseline speedtest values. Latency increase under load dropped to zero, lower ping with no packet loss is observed during VoIP and online gaming during heavy internet usage. Speedtests results with and without SQM: |
| | |
| | [[https://www.waveform.com/tools/bufferbloat?test-id=e101a8fc-f017-4eef-8f90-b27bcb783d62|User's speedtest results with SQM.]] |
| | |
| | ^ Speedtest Results ^^^^^^^^ |
| | | QoS | Download | Upload | Unloaded Ping | DL Latency | UL Latency | Quality grade | Bufferbloat grade | |
| | | None | 532 Mbits | 37 Mbits | 12 ms | +18 ms | +38 ms | B | B | |
| | | SQM | 495 Mbits | 28 Mbits | 12 ms | +0 ms | +0 ms | A+ | A + | |
| |
| 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. | ===== A Little More Tuning ===== |
| |
| You've reduced your connection's bufferbloat! | 1. The steps above will handle latency well, but you may improve this further via adjusting the dl/ul limits and with these steps: |
| ===== A Little More SQM Tuning ===== | |
| |
| 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 limit and retest until latency begins to increase, then go back to a slightly lower value. |
| | * Repeat the same for the Upload speed. |
| | * Use [[https://www.waveform.com/tools/bufferbloat|Waveform]] speedtest to achieve A+ quality and A+ bufferbloat grades when optimal settings are found. |
| | * For DSL, the experiments above may produce download/upload values that are actually //higher// than the original speed test. This is ok, the ATM framing bytes of a DSL link add an average of 9% overhead, and these settings tell SQM how to make up for that overhead. |
| | * For DOCSIS cable, some providers trick speed tests by adding 10-15% over-provisioning for the first 10 seconds (so speed tests look better!). |
| |
| * Increase the Download speed and retest until the latency begins to increase, then go back to a slightly lower value. | 2. Cake is the [[https://www.bufferbloat.net/projects/codel/wiki/Cake/|preferred algorithm]] as it is excellent at mitigating bufferbloat. However, Fq_codel is often a faster, albeit less comprehensive option. One user found [[https://forum.openwrt.org/t/netgear-r6220-sqm-results-downstream-cut-in-half-and-my-optimal-settings/114301|fq_codel gave about 15% higher throughput when CPU limited]] and this [[https://lists.bufferbloat.net/pipermail/cake/2018-April/003384.html|email thread showed similar results]]. |
| * Repeat the same for the Upload speed. | |
| * We recommend you use [[http://dslreports.com/speedtest|DSLReports Speedtest]] and/or [[https://www.waveform.com/tools/bufferbloat|Waveform's Blufferbloat test]] for the tests to achieve A+ quality and A+ bufferbloat 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 [[docs:guide-user:network:traffic-shaping:sqm-details|SQM Details]] and [[https://forum.openwrt.org/t/sqm-setting-question-link-layer-adaptation/2514/9|SQM setting question]]) for efficiency improvements. | 3. To set your link **mpu** (read [[docs:guide-user:network:traffic-shaping:sqm-details|SQM Details]] and [[https://forum.openwrt.org/t/sqm-setting-question-link-layer-adaptation/2514/9|SQM setting question]]) for efficiency improvements. Setting mpu will ensure rate shaping is correct for small packets. |
| |
| 3. Cake is often the [[https://www.bufferbloat.net/projects/codel/wiki/Cake/|preferred algorithm]] as it is robust and efficient to mitigate bufferbloat. However, currently the consensus is that cake bundles almost all features for a typical private internet access link, but fq_codel is now faster, albeit less robust. One user found [[https://forum.openwrt.org/t/netgear-r6220-sqm-results-downstream-cut-in-half-and-my-optimal-settings/114301|fq_codel gave about 10% more performance on a slow CPU]] and this [[https://lists.bufferbloat.net/pipermail/cake/2018-April/003384.html|email thread]]. | 4. Check the [[docs:guide-user:network:traffic-shaping:sqm-details#faq|FAQ]] and [[docs:guide-user:network:traffic-shaping:sqm-details#troubleshooting_sqm|Troubleshooting SQM]] guides for more information. See also: [[:docs:guide-user:network:traffic-shaping:sqm_configuration|SQM configuration]] for advanced options. |
| |
| 4. Check the [[docs:guide-user:network:traffic-shaping:sqm-details#faq|FAQ]] and [[docs:guide-user:network:traffic-shaping:sqm-details#troubleshooting_sqm|Troubleshooting SQM]] guides for more information. | 5. Consider Cake tuning parameters: [[https://man7.org/linux/man-pages/man8/tc-cake.8.html]] |
| |
| 5. Consider Cake tuning parameters on the man page: [[https://man7.org/linux/man-pages/man8/tc-cake.8.html]] | 6. To use SQM it is necessary to disable hardware flow offloading as per [[https://forum.openwrt.org/t/sqm-and-non-sqm-queue-issues-lan-vs-wlan/15433/10|this post]]. |