Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
| docs:guide-user:network:traffic-shaping:sqm [2022/01/14 15:40] – [Configuring the SQM Bufferbloat Packages] update overhead to be consistent with SQM Details page. Using docsis 22 allows for the rare possibility of VLAN tagging at minimal efficiency loss. palebloodsky | docs:guide-user:network:traffic-shaping:sqm [2024/05/10 14:52] – remove a dead link, and small language tweaks palebloodsky | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== SQM (Smart Queue Management) ====== | ====== SQM (Smart Queue Management) ====== | ||
| - | OpenWrt has a pre-built | + | OpenWrt has a package |
| - | OpenWrt calls the package Smart Queue Management (SQM), although it's also called [[wp> | + | |
| - | Bufferbloat is most evident when the link is heavily loaded. It causes bad performance for voice and video conversations, | + | Install '' |
| - | The " | + | ===== Overview ===== |
| - | **TL;DR** Video guide: [[https:// | + | 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. |
| - | Advanced | + | 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. |
| - | **Note**: | + | SQM is heavily CPU dependent. Slower |
| - | ===== Preparation: | + | |
| - | 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 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. |
| - | /* 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 */ | + | |
| - | /* | + | |
| - | To install the //speedtest-netperf// package: | + | |
| - | * From LuCI web GUI: | + | |
| - | * choose **System | + | |
| - | * Or, from cmd: < | + | |
| - | To use the script, ssh to the OpenWRT device and run the following (example results shown, additional options are available): | + | ===== Preparation: |
| - | < | + | |
| - | 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. | + | |
| - | ..................... | + | |
| - | | + | |
| - | Latency: [in msec, 21 pings, 0.00% packet loss] | + | |
| - | Min: 19.125 | + | |
| - | 10pct: | + | |
| - | | + | |
| - | Avg: 31.586 | + | |
| - | 90pct: | + | |
| - | Max: 63.253 | + | |
| - | CPU Load: [in % busy (avg +/- std dev) @ avg frequency, 18 samples] | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | netperf: | + | |
| - | ..................... | + | |
| - | | + | |
| - | Latency: [in msec, 21 pings, 0.00% packet loss] | + | |
| - | Min: 19.627 | + | |
| - | 10pct: | + | |
| - | | + | |
| - | Avg: 21.521 | + | |
| - | 90pct: | + | |
| - | Max: 26.307 | + | |
| - | CPU Load: [in % busy (avg +/- std dev) @ avg frequency, 19 samples] | + | |
| - | | + | |
| - | | + | |
| - | | + | |
| - | netperf: | + | |
| - | </ | + | |
| - | */ | + | |
| - | * When your network is relatively quiet, use DSLReports Speedtest at: http:// | + | |
| - | * A decent alternative to the dslreports test that also helps to asses bufferbloat is waveform' | + | |
| - | * //This is probably a good time to [[docs: | + | |
| - | + | ||
| - | ===== Configuring the SQM Bufferbloat Packages | + | |
| - | The default values quite well for most situations. They represent conservative estimates which is generally desirable compared | + | Before you can optimize your network, you need to know its current state. When your internet |
| + | * Run a speed test from [[https:// | ||
| + | * If you are using this OpenWrt device as an [[docs: | ||
| - | To configure SQM, choose | + | ===== Configuration ===== |
| + | |||
| + | In LuCI go to **Network -> SQM QoS**. The default settings will work, however you can improve performance with settings specific | ||
| - 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 | + | * Set the **Interface name** to your internet |
| - | * 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 |
| * Choose // | * Choose // | ||
| - | * The Advanced Configuration | + | * Advanced Configuration |
| - | - In the **Link Layer Adaptation** tab, choose the kind of link you have (optional, default may also be used): | + | - In the **Link Layer Adaptation** tab, select your link type (optional: set mpu see [[: |
| - | * //For VDSL// - Choose **Ethernet**, | + | * //For VDSL// - Choose **Ethernet**, |
| - | * //For DSL of any other type// - Choose **ATM**, and set overhead 44 | + | * //For DSL of any other type// - Choose **ATM**, and set overhead 44 (mpu 96). |
| - | * //For DOCSIS Cable// - Choose **Ethernet**, | + | * //For DOCSIS Cable// - Choose **Ethernet**, |
| - | * //For true ethernet | + | * //For Ethernet |
| - | * //When in Doubt, it's better to overestimate// | + | * //If unsure, it's better to overestimate// |
| - | - Click **Save & Apply**. That's it! | + | - Click **Save & Apply**. |
| + | |||
| + | That's it! You can confirm mitigation of bufferbloat by re-running the speedtest. Any increased ping during download/ | ||
| + | |||
| + | ===== Results ===== | ||
| + | |||
| + | As an example, the user below is running OpenWrt 23.05 on a [[toh: | ||
| - | 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' | + | [[https:// |
| - | You've reduced your connection' | + | ^ |
| - | ===== A Little More SQM Tuning | + | | QoS | Download |
| + | | None | 532 Mbits | 37 Mbits | 12 ms | +18 ms | +38 ms | B | B | | ||
| + | | SQM | ||
| - | 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. | + | ===== A Little More Tuning |
| - | If you want to spend a few more minutes tuning, do these steps. | + | 1. The steps above will handle latency well, but you may improve this further via adjusting the dl/ul limits and with these steps: |
| - | * Increase the Download speed until the latency begins to increase, then go back to a slightly lower value. | + | * Increase the Download speed limit and retest |
| - | * Do the same for the Upload speed entry. | + | * Repeat |
| - | * 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. | + | * Use [[https://www.waveform.com/tools/ |
| - | * We recommend you use [[http://dslreports.com/speedtest|DSLReports Speed Test]] for the latency tests because it measures both speed and latency at the same time. | + | * For DSL, the experiments above may produce |
| - | | + | * For DOCSIS cable, some providers trick speed tests by adding 10-15% over-provisioning for the first 10 seconds (so speed tests look better!). |
| - | **Note 1:** If you have a DSL link, the experiments above may produce | + | |
| - | **Note | + | 2. Cake is the [[https:// |
| - | **Note 3:** You can also experiment with the other settings | + | 3. To set your link **mpu** (read [[docs: |
| - | **Note | + | 4. Check the [[docs: |
| - | **Note | + | 5. Consider Cake tuning parameters: [[https://man7.org/linux/man-pages/man8/tc-cake.8.html]] |
| - | **Note | + | 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]]. |