SQM QoS for bufferbloat really limits downstream bandwidth

I'm running 18.06.5 on an R7800 and followed the instructions at this wiki page to improve bufferbloat. Interestingly, using 95% or 90% of my max upload/downstream really limits the downstream bandwdith.

For example, without the QoS at all, I get an ave down of 210,000 kbit/s and an ave up of 12,720 kbit/s.

When I use values of 95% or 90% of these max values, the best downstream I can achieve is 160,000 kbit/s ... that is using values of 196,935 or 186,570 for the download. Is that normal? I also tried using a 0 for the download and am finding the same wall around 160,000 kbit/s.

Other settings are as explained on the wiki page, but in summary:
queue discipline = cake
setup scripts = piece_of_cake.qos
per packet overhead = 22 (but also tried 44 with no change)

1 Like

Who is your service provider? what are the speed limits for that service? Are you taking measurements wire/wireless? What do you get when measuring from the ISP equipment?

1 Like

Well, yes and no. The shaper rates are gross rates, while speedtests measure net Goodput (typically TCP/IPv4), so the maximum to expect for your settings would be:

196.935 * ((1500-20-20)/(1522)) = 188.913 Mbps
186.570 * ((1500-20-20)/(1522)) = 178.970 Mbps

That clearly is lower than the set values, but also higher than your ~160 Mbps results.

That seems wrong/odd, with a rate of 0 sqm does not instantiate a shaper at all, would you be willing to spend some time trying to debug this?

So, if you have time and dedication to invest in debugging this, I would like you to post the following information:

  1. disable sqm and run a dslreports speedtest (see https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803 for recommendations how to configure that test and how to link in the results)

  2. enable sqm (with download set to 0 and upload set to 12720) and post the output of:

a) cat /etc/config/sqm
b) tc -s qdisc
c) SQM_DEBUG=1 SQM_VERBOSITY_MAX=8 /etc/init.d/sqm stop ; SQM_DEBUG=1 SQM_VERBOSITY_MAX=8 /etc/init.d/sqm start

  1. run a deslreports speedtest and post the result and post the output of:
    a) tc -s qdisc

This is first to try to understand the situation with the download shaper set to 0, we might need to repeat the same thing for a realistic upload shaper value later.

I agree with @el-guapin that knowing whether you tested over wifi or wired is interesting, and for this set of tests I would like to ask you to test over a wire connection.

Since this seems to be a cable link I would also like to see the output from the "Share Your Results" box of https://www.speedguide.net/analyzer.php to rule out ds-lite and also the output of
ifstatus wan
since this is a bit verbose please only copy the following three fields (your values will be different, I just left mine in for reference)
"l3_device": "pppoe-wan",
"proto": "pppoe",
"device": "eth1.7",

Good luck!

1 Like

If you watch the CPU usage during the test, one core will be maxed-out: I do not think this router can do more with SQM.


You bet, but it seems this is a CPU-bound phenomenon so unless you think otherwise, I will take no action. Please let me know.

In order:

  1. Comcast.
  2. 200 down/12 up
  3. Wired.
  4. I get approx 210 down / 12 up but that is modem --> router --> switch --> PC.

Yep... when I use htop on the router, indeed, I am >99% usage on one core so that solves the mystery! I am a bit disappointed that a 1.70 GHz CPU can be the rate limiter :slightly_frowning_face:

I even switched to the performance governor for that test so wide open throttle.

This leads me to a few questions:

  1. Is a multi-threaded version possible/available?
  2. Is an alternative QoS script that is less CPU intensive an option?

For testing purposes, set your down to 211135, up 13135. Set overhead to 44. post your results

Welcome to the club :slight_smile:

1 Like

Using the dslreports bufferbloat test with those values, I get:
157.1 megabit/s down
12.22 megabit/s up
A for overall
B for bufferbloat
A+ for quality

During the test, running htop on the router itself, I watched one core max out during the download test.

So I have been experimenting with some different parameters and found a MUCH better result:

Max CPU load on 1 core was ~90%
download limit = 196935
upload limit = 12084
22 overhead

178.2 down
11.75 up
A B A+

EDIT: I tried a few times and the results vary a bit... I might record them and post ave with SD but these settings are clearly better than the ones I used when I started this thread.

Well, with sqm's download set to 0 it should still help on the uplink while not affecting the download side at all, so it might still be worth it...

Over in the KONG thread about the R7800 there was advise about how to get more out of sqm on those, see https://forum.openwrt.org/t/kong-ipq806x-builds/43640/360?u=moeller0 as an entry point.

Not an option, as far as I can tell, more or less all traffic shapers are equally CPU intensive.

I would be intersted in the output of:
opkg list-installed | grep -e sqm
to see which sqm-scripts version you run, we actually included some measures into recent sqm-scripts that should allow you to trade in some latency for somewhat higher bandwidth, but that has not benn properly tested yet.

With your current settings the theoretic maximum would be:
196.935 * ((1500-20-20)/(1522)) = 188.912
12.084 * ((1500-20-20)/(1522)) = 11.591

so this looks pretty close... It would help though, if you could post the links to dslreport's detailed test results...

You bet:

# opkg list-installed | grep -e sqm
luci-app-sqm - 1.2.4-1
sqm-scripts - 1.2.4-1

I didn't log into dslreports, just browsed to it. I don't see an obvious place to get the link you asked for...

Okay, these are old, but you are lucky that you stay below 200Mbps in the simple.qos configuration...
current would be 1.4 I believe.

Well, than get a free registration and log in, the instructions in https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803 should works, let me know if there are issues with those.

But in short, run a test, wait for the overview results, click the "Results + Share" button, there go to the Sharing section, click "Linked BB Code" and copy the link here:

Seems to work for non registered users as well...

Click on "share results: this will bring you to results page.

Interesting... wonder why the repo isn't supplying it current version?

I will log in to dsl reports and share some tests... but since we figured out that the issue was the CPU-bound nature, what would these data tell us?

Because you are not running 19.07

opkg list | grep sqm
luci-app-sqm - 1.4.0-2
sqm-scripts - 1.4.0-2

I believe that is because the openwrt version has only recently been updated (at least fort 19.07), and 18.06 might never been updated at all (never change a running system).

Well, in the upload only shaping condition you should not be CPU limited (nor do you seem to be with fq_codel/simple.qos) and then the dslreport's bufferbloat plots are helpful in confirming proper functionality. But obviously that is your choice :wink:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.