dlakelan, my priority aim here is to address the bufferbloat with WiFi connections. I found that by set sqm to wlan interfaces helps a lot.
It's an MT7621AT processor. That's a dual core 880MHz MIPS. Those support offloading if I understand correctly, which is the only way you're going to route 700Mbps, but offloading is NOT compatible with SQM, so if you have offloading enabled then SQM isn't actually running.
Are you saying that you are able to instantiate a 700Mbps SQM interface on the WAN both directions, connect via ethernet so the wifi isn't involved, and run a speedtest without offloading and get the full 700Mbps throughput? Because that doesn't match anything else I've seen posted to this forum from others.
The benefit you get from putting SQM on wifi might be because you have offloading, and therefore the WAN SQM isn't working.
1 Like
Ah, my question is about running a traffic shaper at 700 Mbps which is considerably more work than normal routing at 700 Mbps.
dlakelan, I am aware of offloading and mine is set off, and shaping is only one way for wan, partly due to the router not powerful enough, and also the incompatibility with wlan sqm settings.
FYI, just confirmed that this 860L really can handle around 660Mbps egress on wan.
1 Like
660Mbps egress on WAN with SQM is impressive. What are your bufferbloat scores with that setting and a wired connection?
I concurr, impressive, could you by any chance run a dslreports speedtest and post the results here, please? (See https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803 for ecommendations for that test and how to link the results here in the forum)
Well, there should be no incompatibility, could you also post the output of cat /etc/config/sqm please?
I just did a speed test using my j1900 and ATT gigabit fiber. It reached 663 Mbps down and 580 up, peak overall CPU usage reached about 50%, with one core peaking at about 80% and devoted entirely to softirq, two other cores at 40% softirq each, and one core free for other processes...
You can see why I am a bit skeptical of an 880MHz dual core MIPS doing the same thing.
Here's my sqm config:
config queue 'eth1'
option qdisc_advanced '0'
option linklayer 'none'
option debug_logging '0'
option verbosity '5'
option qdisc 'fq_codel'
option script 'simplest.qos'
option interface 'eth0.2'
option enabled '1'
option upload '700000'
option download '0'
config queue
option debug_logging '0'
option verbosity '5'
option qdisc 'fq_codel'
option linklayer 'none'
option interface 'wlan1'
option script 'simplest.qos'
option qdisc_advanced '0'
option enabled '1'
option upload '12000'
option download '7000'
config queue
option debug_logging '0'
option verbosity '5'
option qdisc 'fq_codel'
option linklayer 'none'
option interface 'wlan0'
option qdisc_advanced '0'
option script 'simplest.qos'
option enabled '1'
option download '75000'
option upload '120000'
If I set download of eth0.2 to a non-zero, like 500000, the bufferfloat test of lan will get an A+, while both wlans' upload bufferbloat will actually bloat.
If you set the 500Mbps download on WAN and also keep the wifi SQM does it still bloat? If so, this indicates probably running out of CPU. The slowest queue controls.
Basically your results are expected. The router receives up to 700Mbps of packets from WAN, but can only send a couple tens to 100 megabits through the wifi, so you get a huge queue at the WiFi. by restricting your two wifi values to 12Mbps and 120Mbps you are managing those send queues. The only problem will be when for example you connect to wlan0 via wifi from "far away" so that the signal is not great and your modulation rate is say 32Mbps, while the queue assumes 120Mbps can pass. You will still get bufferbloat there.
The thing is that there is no single number you can put on wifi so it will always give good results no matter how far away you connect from, because wifi will degrade down to only 6Mbps or even 1Mbps if you still allow old modulation rates.
@dlakelan, still applying sqm to wlan interfaces would speed up surfing, FaceTime quite a bit, I am going to keep it this way, at least it cannot get things worse.
1 Like
For bufferbloat, I might be confused.... is the advice here NOT to apply SQM to the "WAN/WAN6" but to the "wlan0"? I currently have SQM applied to "WAN/WAN6" and nothing else.
Not exactly. What I am doing is applying SQM to WAN/WAN6 on egress direction, and apply extra SQM to both wlan0 and wlan1. Testing shows wlans connection will get bloated without the extra SQM.
I am not surprised. I was able to shape a bit over 700 Mbit in my testing with iperf3 on my mt7621 device with one computer connected to WAN, and another on LAN. NAT and firewall were both enabled. It did gigabit speeds in the same configuration with SQM turned off with CPU cycles to spare. That was way before hardware or software flow offload was even a thing. Even back then my tests with met with skepticism. Glad somebody managed to reproduce those 
As for your WiFi bloat issues, make sure you use 19.07.0 or a snapshot, since those are currently the only versions with airtime fairness enabled. Still, as the shaping bottleneck was a little bit over 700 Mbit in my testing, with WiFi thrown into the mix you are probably running out of CPU cycles if you have a 700 Mbit WAN connection.
1 Like
Impressive, this test really looks decent...
A little bit confusing here, since the test with WiFi connection never exceed much more than 200 Mbit, how should the cpu cycles drained already?
Any bufferbloat testing result with WiFi connection on 19.07.0 or main branch, with SQM only applying to WAN/WAN6?
For now I might need more convincing facts for me to consider upgrading.
managing the wifi hardware requires a bunch of cpu cycles on top of the packet management. So I'd expect your wifi CPU saturation to be considerably lower than your wired CPU saturation... Still If you can handle 700Mbps wired, then I'd expect you to do 300 or 400 at least by WiFi...
Remember though that your WAN could receive 700 and then the queue on the wifi throws it away, but you still have to process the 700. That shouldn't happen for long periods, but it could spike like that.
That totally make sense, since the remote server never know your're access through WiFi.
Well, airtime fairness is quite an interesting feature. By default WiFi does/did throughput fairness, so one slow link to say an old device with only 802.11b or a modern device quite far away could severely decrease the aggregate throughput of the wifi network, as the slow devices got way more airtime. Since the contended respurce in wifi is not so much throughput but rather transmit opportunities or "airtime" it makes sense to not try to dole out equal "throughput" to all devices but rather share airtime fairly, which in effect will cause less of an aggregate throughput loss AND will also in general decrease the latency (as slower devices will not hog the airtime for long durations any more if there are other stations trying to receive data). In short airtime fairness is quite an interesting feature, which might even make the sqm instance on your wlans superfluous (as Linux airtime fairness implementation works by implementing fq_codel inside the wifi driver, and in that situation, no additional traffic shaper is required). So if 19.07 actually offers working airtime fairness for the 860, that would for me be a strong reason to update (in addition to the fact that 18.06 will be on the way out). But that obviously is a policy decision everybody needs to take for their own network.
If I remember correctly, airtime fairness only apply to 2.4G WiFi, or I missed something?
Edit: OK, did some research and found the airtime fareness patch was moved to mac80211, to make it usable from other drivers, on Thu, 22 Feb 2018, see.
I guess this means airtime fairness is not restricted to ath9k now. Just need to prove if it's work as good as it supposed to be.