Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| docs:guide-user:network:traffic-shaping:sqm [2018/03/03 20:13] – ↷ Page moved from docs:user-guide:network:traffic-shaping:sqm to docs:guide-user:network:traffic-shaping:sqm bobafetthotmail | docs:guide-user:network:traffic-shaping:sqm [2024/11/07 18:49] (current) – further streamline config language palebloodsky | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Smart Queue Management | + | ====== |
| - | LEDE 17.01.0 has pre-built packages | + | OpenWrt supports SQM for mitigating [[wp> |
| - | Bufferbloat is most evident when the link is heavily loaded. It causes bad performance for voice and video conversations, | + | ===== Overview ===== |
| - | The " | + | Bufferbloat |
| - | **TL;DR** Install LEDE 17.01 newer, and follow the video at: https://www.youtube.com/ | + | SQM is an integrated system that performs per-packet/ |
| - | ===== Preparation: Measure Your Current Speed and Latency ===== | + | SQM is heavily CPU dependent. Slower devices may be unable to [[https:// |
| - | Before you can optimize your network, you need to know its current state. Run a speed test to find your down/upload link speeds. | + | SQM is incompatible with hardware flow offloading which bypasses part of the kernel as per [[https:// |
| - | - When your network | + | |
| - | | + | |
| - | + | ||
| - | ===== Installing the SQM Bufferbloat Packages in LEDE ===== | + | |
| - | Install the // | + | ===== Preparation: Measure Your Current Speed and Latency ===== |
| - | - Uninstall // | + | Before you can optimize your network, you need to know its current state. |
| - | - Install the //luci-app-sqm// package. It will automatically install other required packages. To do this: | + | |
| - | * From the LuCI web GUI, go to **System -> Software**, then click **Update Lists** | + | |
| - | * Click the **Available packages** tab, and find // | + | |
| - | - Start and Enable the SQM scripts. To do this, choose | + | |
| - | * Click Start to start the SQM process | + | |
| - | * Click Enable to start the SQM process when the route reboots | + | |
| - | ===== Configuring the SQM Bufferbloat Packages in LEDE ===== | + | ===== Installation |
| - | The default values described below work quite well for most situations. You may be able to improve performance by experimenting with settings, see [[# | + | Install '' |
| - | To configure SQM, choose | + | In LuCI go to **Network -> SQM QoS**: |
| - In the **Basic Settings** tab: | - In the **Basic Settings** tab: | ||
| * Check the **Enable** box | * Check the **Enable** box | ||
| - | * Set the **Interface | + | * Set the **Interface** to your internet |
| - | * Set the **Download** and **Upload** speeds to 80-95% of the speed you measured | + | * Set the **Download** and **Upload** speeds to 90% of what you measured in Preparation |
| - | - In the **Queue Discipline** tab, you can leave the settings at their default. | + | - 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: | + | - In the **Link Layer Adaptation** tab, select your link type (setting mpu is optional see [[: |
| - | * //For VDSL// - Choose | + | * //VDSL// - choose |
| - | * //For DSL of any other type// - Choose | + | * //DSL of any other type// - choose |
| - | * //For Cable or other kinds of connections// - Choose | + | * //DOCSIS |
| - | - Click **Save & Apply**. | + | |
| + | * // | ||
| + | * //If unsure// - it's better to overestimate, | ||
| + | - Click **Save & Apply**. | ||
| - | Measure your latency again with the speed test. You should notice that the measured | + | Done! You can confirm results by re-running |
| - | Note, sqm-scripts shaper interprets the bandwidth values as gross bandwidth, while speedtests typically report TCP/IPv4 good-put. So how to estimate what sppedtest result is a good match for a given shaper bandwidth? Just use the following formula and plug in the correct values: | + | ===== Results ===== |
| - | ${ShaperBandwidth} * (${pMTU} | + | As an example, the user below is running OpenWrt 23.05 on a [[toh: |
| - | with: pMTU typically around 1500, IPv4Header = 20 bytes, TCPHeader = 20 bytes, Overhead the value you specified in the shaper (or typically 14 bytes if you did not explicitly configured this) | + | ^ |
| + | | QoS | Download | ||
| + | | 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 + | | ||
| - | E.g.: for a DOCSIS link with 18 bytes overhead you at best get a 100-100*(1500-20-20)/ | + | ===== A Little More Tuning |
| + | 1. The steps above will handle latency well but you can improve this further with these steps: | ||
| - | You've reduced your connection' | + | * Increase the Download speed limit setting and retest until bufferbloat |
| - | ===== A little about tuning | + | * Repeat the same for the Upload speed. |
| + | * Test this using [[https:// | ||
| + | * For DSL, the experiments above may produce download/ | ||
| + | * For DOCSIS cable, some providers trick speed tests by adding 10% over-provisioning for the first 10 seconds (so speed tests look better!). | ||
| - | The steps above will control latency well without additional effort. The 80-95% figures mentioned above are good first-cut estimates, but you can often gain more speed while still controlling latency by making | + | 2. Cake is the [[https:// |
| - | The most important settings are the Download and Upload speeds. While it may seem counterintuitive, | + | 3. To set your link **mpu** read [[docs: |
| - | Adjust the Download speed upwards until the latency begins to increase, then enter a slightly lower final value. One good test for this is the [[http:// | + | 4. See [[:docs: |
| - | **Note:** 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. | + | 5. Consider Cake parameters: [[https://man7.org/linux/man-pages/man8/tc-cake.8.html]] |
| - | + | ||
| - | **Note:** If you use a cable modem, you should use a speed test that runs for a longer time. Cable modem makers have gamed speed tests thoroughly by using " | + | |
| - | + | ||
| - | You can also experiment with the other settings (read the "the details" | + | |
| - | ===== SQM: The Longer Description ===== | + | |
| - | + | ||
| - | Smart Queue Management (SQM) is our name for an intelligent combination of better packet scheduling (flow queueing) techniques along with with active queue length management (AQM). | + | |
| - | + | ||
| - | LEDE has full capability of tuning the network traffic control | + | |
| - | + | ||
| - | Current versions of LEDE have SQM, fq_codel, and cake built in. These algorithms were developed as part of the [[http:// | + | |
| - | + | ||
| - | To use SQM in your LEDE router, use the **SQM QoS** tab in the web interface. This will optimize the performance of the WAN interface (generally eth0) that connects your router to the ISP/the Internet. There are three sub-tabs in the **SQM QoS** page that you may configure: | + | |
| - | + | ||
| - | * **Basic Settings** sets the download and upload speeds of the uplink. Be sure to read about the adjustment you should make when entering speeds. | + | |
| - | * **Queue Discipline** selects which queueing discipline to use on the WAN link. The default settings are good in almost every case. | + | |
| - | * **Link Layer Adaptation** lets LEDE calculate the proper overheads for WAN links such as DSL and ADSL. If you use any kind of DSL link, you should review this section. | + | |
| - | + | ||
| - | + | ||
| - | ==== SQM: Basic Settings Tab ==== | + | |
| - | + | ||
| - | Set the **Download** and **Upload** speeds in the web GUI for the speed of your Internet connection. To do this | + | |
| - | + | ||
| - | - Get a speed measurement. See [[# | + | |
| - | - Set Download and Upload according to those link speeds. See examples below. | + | |
| - | - Be sure to check the **Enable** box and set the Interface for your WAN interface. | + | |
| - | - (Optional) Read [[# | + | |
| - | + | ||
| - | **Example 1:** If your your provider boasts "7 megabit download/ | + | |
| - | + | ||
| - | **Example 2:** If you have measured your bandwidth with a speed test (be sure to disable SQM first), set the **Download** and **Upload** speeds to 95% of those numbers. For example, if you have measured 6.2 megabits down and 0.67 megabits up (6200 kbps and 670 kbps, respectively), | + | |
| - | + | ||
| - | **Basic Settings - the details...** | + | |
| - | + | ||
| - | SQM is designed to manage the queues of packets waiting to be sent across the slowest (bottleneck) link, which is usually your connection to the Internet. LEDE cannot automatically adapt to network conditions on DSL, cable modems or GPON without any settings. Since the majority of ISP provided configurations for buffering are broken today, you need take control of the bottleneck link away from the ISP and move it into LEDE so it can be fixed. You do this by entering link speeds that are a few percent below the actual speeds. | + | |
| - | + | ||
| - | Use a speed test program or web site like the [[https://www.dslreports.com/speedtest|DSL Reports Speed Test]] to get an estimate of the actual download and upload values. After setting the initial Download and Upload entries, you should feel free to try the suggestions at [[# | + | |
| - | ==== SQM: Queue Discipline Tab ==== | + | |
| - | + | ||
| - | The **Queue Discipline** tab controls how packets are prioritized for sending and receipt. The default settings shown here work very well for nearly all circumstances. Those defaults are: | + | |
| - | * //cake// queueing discipline | + | |
| - | * // | + | |
| - | * //ECN// for inbound packets | + | |
| - | * //NOECN// for outbound packets | + | |
| - | * The default values of the **Advanced Configuration** work fine | + | |
| - | + | ||
| - | **Queueing Discipline | + | |
| - | + | ||
| - | The default | + | |
| - | + | ||
| - | The default // | + | |
| - | + | ||
| - | Explicit Congestion Notification (ECN) is a mechanism for notifying a sender that its packets are encountering congestion and that the sender should slow its packet delivery rate. Instead of dropping a packet, fq_codel marks the packet with a congestion notification and passes it along to the receiver. That receiver sends the congestion notification back to the sender, which can adjust its rate. This provides faster feedback than having the router drop the received packet. //Note:// this technique requires that the TCP stack on both sides enable ECN. | + | |
| - | + | ||
| - | At low bandwidth, we recommend that you turn ECN off for the Upload (outbound, egress) direction, because fq_codel handles and drops packets before they reach the bottleneck, leaving room for more important packets to get out. For the Download (inbound, ingress) link, we recommend you turn ECN on so that fq_codel can inform the local receiver (that will in turn notify the remote sender) that it has detected congestion without loss of a packet. | + | |
| - | + | ||
| - | The " | + | |
| - | + | ||
| - | * **Hard limit on ingress queues:** This is a limit the ingress (inbound) queues, measured in packets. Leave it empty for default. | + | |
| - | * **Hard limit on egress queues:** This is a limit on the egress (outbound) queues. Similar to the ingress hard limit. | + | |
| - | * **Latency target for ingress:** The codel algorithm specifies a target, expressed in msec. Leave empty or use " | + | |
| - | * **Latency target for egress:** The target setting for the egress queues. Similar to the ingress latency target. | + | |
| - | * **Advanced option string for ingress:** This string passes additional parameters to the ingress queueing discipline. There is no error checking, so enter carefully. Empty is the default. | + | |
| - | * **Advanced option string for egress:** Similar to the ingress advanced option string. | + | |
| - | + | ||
| - | Please note that if any of the " | + | |
| - | ==== SQM: Link Layer Adaptation Tab ==== | + | |
| - | + | ||
| - | Set the Link Layer Adaptation options based on your connection to the Internet. The general rule for selecting the Link Layer Adaption is: | + | |
| - | + | ||
| - | * Choose **ATM: select for e.g. ADSL1, ADSL2, ADSL2+** and set the Per-packet Overhead to 44 bytes if you use any kind of DSL/ADSL connection to the Internet (that is, if you get your internet service through a telephone line). | + | |
| - | * Choose **Ethernet with overhead: select for e.g. VDSL2** and set the Per-packet Overhead to 8 if you know you have a VDSL2 connection. If you have a cable modem, see the **Ethernet with Overhead** details below. | + | |
| - | * Choose **none (default)** if you use Fiber, direct Ethernet, or another kind of connection to the Internet. All the other parameters will be ignored. | + | |
| - | + | ||
| - | If you are not sure what kind of link you have, first try using " | + | |
| - | + | ||
| - | **Link Layer Adaptation - the details…** | + | |
| - | + | ||
| - | Various link-layer transmission methods affect the rate that data is transmitted/ | + | |
| - | + | ||
| - | * **ATM:** It is especially important to set the Link Layer Adaptation on links that use ATM framing (almost all DSL/ADSL links do), because ATM adds five additional bytes of overhead to a 48-byte frame. Unless the SQM algorithm knows to account for the ATM framing bytes, short packets will appear to take longer to send than expected, and will be penalized. For true ATM links, one often can measure the real per-packet overhead empirically, | + | |
| - | * **Ethernet with Overhead:** SQM can also account for the overhead imposed by VDSL links - add 8 bytes of overhead. Cable Modems (DOCSIS) are known to typically use 28 bytes of overhead in the upstream direction but only 14 bytes in the downstream direction. If your version of SQM only supports to specify one value for the overhead, select 28 Bytes… UPDATE: while the reported numbers are not wrong per se, it turned out that the user traffic shaper mandated? by DOCSIS systems only account for L2 ethernet frames including the frame check sequence (FCS), so the 2017 recommendations for cable users is to set both up- and downstream overhead to 18 bytes (6 bytes source MAC, 6 bytes destination MAC, 2 bytes ether-type, 4 bytes FCS). | + | |
| - | * **None:** Fiber, and direct Ethernet connections generally do not need any kind of link layer adaptation. | + | |
| - | + | ||
| - | The " | + | |
| - | + | ||
| - | Unless you are experimenting, | + | |
| - | ===== Selecting the optimal queue setup script ===== | + | |
| - | + | ||
| - | **TL;DR:** Use cake, not fq_codel. | + | |
| - | + | ||
| - | //Note:// As of early 2017, cake is an improvement both in speed and capabilities over the original fq_codel algorithm first deployed in May 2012. cake is in every way better than fq_codel. The following description is preserved for historical information. | + | |
| - | + | ||
| - | The right queue setup script (simple, hfsc_lite, ...) for you depends on the combination of several factors like the ISP connection' | + | |
| - | + | ||
| - | This was tested with WNDR3700 running trunk with kernel 4.1.16 and SQM 1.0.7 with simple, hfsc_lite and hfsc_litest scripts with SQM speed setting 85000/10000 (intentionally lower than ISP connection speed), 110000/ | + | |
| - | + | ||
| - | wired 85/10 wired 110/ | + | |
| - | | + | |
| - | Simple | + | |
| - | hfsc_lite | + | |
| - | hfsc_litest | + | |
| - | + | ||
| - | (" | + | |
| - | + | ||
| - | With wired 85/10 the experience was almost identical with all four qdisc strategies in SQM. Approx. 20 Mbit/s download / 2.1 Mbit/s upload and 19 ms latency shown in the flent summary graph. | + | |
| - | + | ||
| - | With wired 110/15 there was more difference. Interestingly " | + | |
| - | + | ||
| - | But when the LAN client connected with Wifi to the router with 110/15 limits, " | + | |
| - | + | ||
| - | At least on the tested setup, the download speed using wifi and SQM " | + | |
| - | + | ||
| - | The key message of this note is that the right setup script for you will depend on your connection, your router and your LAN clients. It pays off to test the various setup scripts. | + | |
| - | ===== Making cake sing and dance, on a tight rope without a safety net ===== | + | |
| - | + | ||
| - | **By now, we hope the SQM message has been clear: stick to the defaults and use cake.** | + | |
| - | + | ||
| - | But cake offers new options that make it the nicest and most complete shaper for a typical home network: Per-Host Isolation in the presence of network address translation (NAT), so that all hosts' traffic shares are equal. (You can choose to isolate per-internal or per-external host IP addresses, but typically fairness by internal host IPs seems in bigger demand.) | + | |
| - | + | ||
| - | A quick aside about Network Address Translation (NAT): ISPs usually assign only one external IP address to each customer. | + | |
| - | The home router assigns unique internal addresses for each computer in the home, and uses a technique called NAT (or " | + | |
| - | + | ||
| - | NAT works pretty well, too, but causes problems when shaping traffic. | + | |
| - | Since all the traffic going to/from the ISP has the same external IP address, cake treats every traffic //flow// (or //stream// or // | + | |
| - | But since a BitTorrent client can start many BitTorrent streams, the second machine can get "more than its share" of the capacity. | + | |
| - | + | ||
| - | Recent versions of cake (LEDE 17.01.0 and newer) have two options that avoid this problem: | + | |
| - | + | ||
| - | - Cake can now access the kernel' | + | |
| - | - Cake can use the information about true source and destination addresses to control traffic from/to internal external hosts by true IP address, not per-stream. | + | |
| - | + | ||
| - | Cake's original isolation mode was based on //flows//: each stream was isolated from all the others, and the link capacity was divided evenly between all active streams independent of IP addresses. More recently cake switched to triple-isolate, | + | |
| - | In that mode, Cake mostly does the right thing. | + | |
| - | It would ensure that no single stream and no single host could hog all the capacity of the WAN link. | + | |
| - | However, it can't prevent a BitTorrent client - with multiple connections - from monopolizing most of the capacity. And running speedtests from multiple internal hosts to the same speedtest server can give unpredictable results. | + | |
| - | + | ||
| - | Cake now uses the true source/ | + | |
| - | + | ||
| - | **To enable Per-Host Isolation** Add the following to the “Advanced option strings” (in the // | + | |
| - | + | ||
| - | For ingress queueing disciplines: | + | |
| - | + | ||
| - | For egress queueing disciplines: | + | |
| - | + | ||
| - | **Notes: | + | |
| - | + | ||
| - | * " | + | |
| - | + | ||
| - | * " | + | |
| - | + | ||
| - | * Enter these strings carefully and exactly. If things do not seem to work, your first troubleshooting step should be to clear these advanced option strings! | + | |
| - | + | ||
| - | * At some point in time, these advanced cake options may become better integrated into luci-app-sqm, | + | |
| - | + | ||
| - | * This discussion assumes SQM is instantiated on an interface that directly faces the internet/ | + | |
| - | + | ||
| - | ===== FAQ ===== | + | |
| - | + | ||
| - | **SQM seems to be confused, my measured download speed is actually close to my configured upload speed:** | + | |
| - | + | ||
| - | Depending on the directionality of the interface with the directionality towards the internet that is not unexpected; try to flip the values in the GUI and see whether measured values better match your expectancy. | + | |
| - | + | ||
| - | **SQM seems confused, both download and upload bandwidth in speedtests measure around the lower value of the configured download and upload bandwidth: | + | |
| - | + | ||
| - | This situation can arise when using a router that uses one of its switch ports as the WAN port and only has one CPU to switch port; assuming the cpu port to the switch is eth0 and VLAN 2 is used for WAN, VLAN 1 for LAN;in that case the appropriate WAN interface from sqms perspective is eth0.2. Instantiating sqm on eth0 (note the lack of the VLAN tags) will make sure that eth0.2 is effectively throttled to min(download_bandwidth, | + | |
| - | + | ||
| - | **How to figure out which interface is actually connected to the internet: | + | |
| - | + | ||
| - | | From the **Network-> | + | |
| - | | The WAN port box shows the \\ name of the WAN interface: | + | |
| - | \\ | + | |
| - | '' | + | |
| - | \\ | + | |
| - | The command above might display: | + | |
| - | \\ | + | |
| - | '' | + | |
| - | \\ | + | |
| - | which means '' | + | |
| - | if you want the typical "shape my internet access" | + | |
| - | + | ||
| - | + | ||
| - | ===== Troubleshooting SQM ===== | + | |
| - | + | ||
| - | The commands below help to collect the information required to debug problems with SQM. | + | |
| - | To use them, [[: | + | |
| - | each line, one at a time. | + | |
| - | Then copy/paste the entire terminal session in your report. | + | |
| - | + | ||
| - | Display all currently defined sqm instances (enabled and disabled): | + | |
| - | + | ||
| - | cat / | + | |
| - | + | ||
| - | Display all information about the WAN interface: | + | |
| - | + | ||
| - | ifstatus wan | + | |
| - | + | ||
| - | Display relatively detailed output of the process of stopping and starting SQM: | + | |
| - | + | ||
| - | SQM_DEBUG=1 SQM_VERBOSITY_MAX=8 / | + | |
| - | + | ||
| - | Display the log file created by the commands above: | + | |
| - | + | ||
| - | cat / | + | |
| - | + | ||
| - | Display the logread output of the sqm start and stop: | + | |
| - | + | ||
| - | logread | grep SQM | + | |
| - | + | ||
| - | Display the // | + | |
| - | + | ||
| - | tc -d qdisc | + | |
| - | + | ||
| - | Display the // | + | |
| - | + | ||
| - | tc -s qdisc | + | |
| - | + | ||
| - | Now generate some traffic through the router (and the SQM instance). The easiest way to do this is to run the DSLReports Speedtest ([[http:// | + | |
| - | + | ||
| - | Now display the '' | + | |
| - | + | ||
| - | tc -s qdisc | + | |
| - | + | ||
| - | Finally, copy/paste the entire session into your report. | + | |