test 2 with same settings and fq_codel/simplest_tbf
test 3 with 0 download/19500 upload and fq_codel
So from your test I think the first one should be the best setting? But 195mbps is not 5-10% of 200mbps, I should leave 195 or is better set something less?
You should test with various overhead values. The ISPs have so varying protocols, that the generic advice about overhead per connection type may not hold true. (I get best results with either 0 or 18)
I have R7800 with a connection of 200/60
with up-to-date master OpenWrt SNAPSHOT, r19689-19ef3b54f4
But interestingly there are errors when SQM is restarted:
root@router1:/etc/config# /etc/init.d/sqm restart
SQM: Stopping SQM on eth0.2
SQM: ERROR: cmd_wrapper: tc: FAILURE (2): /sbin/tc qdisc del dev eth0.2 ingress
SQM: ERROR: cmd_wrapper: tc: LAST ERROR: RTNETLINK answers: Invalid argument
SQM: Starting SQM script: simple.qos on eth0.2, in: 190000 Kbps, out: 57000 Kbps
SQM: ERROR: cmd_wrapper: tc: FAILURE (2): /sbin/tc qdisc add dev eth0.2 handle ffff: ingress
SQM: ERROR: cmd_wrapper: tc: LAST ERROR: RTNETLINK answers: File exists
SQM: ERROR: cmd_wrapper: tc: FAILURE (2): /sbin/tc filter add dev eth0.2 parent ffff: protocol all prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb4eth0.2
SQM: ERROR: cmd_wrapper: tc: LAST ERROR: RTNETLINK answers: Invalid argument
We have an error talking to the kernel
SQM: WARNING: sqm_start_default: simple.qos lacks an ingress() function
SQM: simple.qos was started on eth0.2 successfully
To me it looks like there may be currently something wrong with the sqm / tc / firewall co-operation, possibly related to the download side. tc -s -d qdisc show does not show stats for the download side.
I you value smooth browsing, look for settings that give you an A score for bufferbloat and then tweak parameters for getting highest possible throughput.
The "5-10%" is meant to be left free for protocol traffic, so that you use 90-95% of the bandwidth. 195 is 97.5% of 200, but that 5 Mbit left free is likely fine.
But if your case the download side is not that crucial. The narrow upload causes you more trouble, as you have 200/20 asymmetric connection.
Okay thanks, but in the end I discovered that my trouble was only with speedtest.net, also on DSLreports the speed is normal. On Speedtest.net I can't go over 90mbps with SQM enabled. I have no idea why!
Another point is that, as the OpenWRT tutorial reports, I should test without SQM (and I get about 170/180mbps) and then set 90/95% of it, like 160mpbs i.e., but this doesn't work good for me, I got very low speedtest and hight bufferbloat.
If I set 190/195mbps (that exceed my speed tests without SQM), I get a normal speed of 130-140mbps and low bufferbloat.
So I have no idea why. Anyway I would left irq balance active.
PS: I don't have errors and tc -s -d qdisc show shows the stats correctly here:
That would very much indicate that your bufferbloat is not caused by your router (or that there are transient CPU overload conditions that randomly affect some tests but not others)...
If you want to dive deeper into this just holler, there is no guarantee for a positive outcome though....
Maybe... if the shaper rate and per-packet-overhead is set correctly there is little need to leave room for protocol traffic. For ingress leaving some room is somewhat important as SQM needs to create an artificial bottleneck, if the SQM-rate is the >= as the upstream rate then in download/ingress SQM will never built up a queue (all queueing happens in the upstream device) and will hence not be able to effectively control bufferbloat (because it never sees it). Cake's ingress keyword helps a bit in that it makes cake's control loop look primarily at the rate of incoming traffic and not at the traffic leaving cake, but that still requires that the configured download rate in cake is smaller than the true rate.
Which tc version and OpenWrt version are you running?
Unfortunately at the moment I can't test wired, but anyway both the services are running wireless, so it should be similar. I suspect the weird difference also wired.
I get vastly different results on speedtest.net depending on the browser I use. Firefox is fastest. Chrome is a dog on speedtest.net. Best try to use iperf3 instead
Funny thing is that with every client (iPhone macOS iPad) on my lan, only with Speedtest.net app/website, with SQM enabled, can’t go over 90mbps, disable SQM and the speed goes back to 150/160mbps.
But with other Speedtest like dslreports or waveform, the speed is normal (130/150mbps) also with SQM enabled.
I don’t know, can’t understand what is going on with Speedtest.net and SQM. Maybe because it sends multiple connections and the the SQM are cutting its bandwitch? Could be possible?!
Strictly speaking, what stops us from using iperf to measure internet access speed is mostly the lack of fast enough and publicly reachable servers on the internet, specifically at the desired locations in regards to one's own ISP. But there are some iperf servers out there which can be used (google is your friend when trying to find them).
Not really, essentially all speedtests default to multiple connections nowadays, so it is unlikely for that to be your problem. But ATM we have too little data to even speculate...
I haven't tought about it.