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)
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?
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:
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
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",
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:
Comcast.
200 down/12 up
Wired.
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
I even switched to the performance governor for that test so wide open throttle.
This leads me to a few questions:
Is a multi-threaded version possible/available?
Is an alternative QoS script that is less CPU intensive an option?
So I have been experimenting with some different parameters and found a MUCH better result:
Max CPU load on 1 core was ~90% Settings:
download limit = 196935
upload limit = 12084
fq_codel
simplest.qos
22 overhead
Result
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.
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...
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:
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