Since I switched main router to D-Link DIR-860L B1, I started trying address bufferbloat issues.
It seems that simple egress limiting for wan with fq_codel and simplest.qos is quite enough for my fiber to achieve 700Mbps upload and matching download, with A quality for bufferbloat score of DLS speed test.
As for the 2 wlans, it's not enough with that setting. I have to apply SQM to both wlan0 and wlan1 interfaces to get a decent bufferbloat score.
I wonder if it's standard with my above mentioned settings? And, why SQM is needed to wlan interfaces?
BTW, my 2 wlans are set to route to wan directly following guest wlan setting.
With a 700Mbps WAN, the slowest point in an internet -> client machine chain is the wifi (at least most of the time) not the WAN as it would have been in the past.
Unfortunately, the WiFi modulation rate varies with conditions, and so there's no easy way to ensure reasonably low latency all the time.
The best strategy is not to install SQM on the wifi interfaces, but to DSCP tag high priority packets, in which case the WMM queues will reduce the latency for important packets.
Also, I'm very surprised your device can keep up with 700Mbps SQM even with "simplest" QoS. That's still 58k packets a second to do firewall, NAT, and QoS.
Mmmh, sqm requires you to set fix rate limits and will only work well, if these limits are below the actual wifi link rate it can work (and considerably so, for wifi I would guess you need to set the shaper to 60-70% of the reported stable link rate). But since wifi link rates depend on your RF environment and distance to the router, they typically are not stable but vary over time, making the sqm approach somewhat sub-optimal for wifi...
For the ath9k and more recently for the ath10k atheros/qualcomm wifi driver there is an airtime fairness mode implemented which does fq_codel in the wifi driver itself (which nows the link rate and hence can always work with a decent and recet estimate of the available linkrate) which helps quite a lot. I was under the impression that this would work for your mediatek based radio as well. I wonder why you see issues at all.
Not sure what's the case for others, but applying SQM to WiFi interface do improve the latency significantly after some adjusting based on tests.
The important thing is you should NOT set ingress limit, and for WiFi interface downloading/uploading is the opposite order as usual. It took me some time to figure it out.
It is quite obvious for the massive delay when surfing or receiving e-mails, I didn't even realized the delay issue at first, before bufferbloat pops up before my eyes.
After some initial setting with applying sqm to wlans interface, I am enjoying the responsiveness that WiFi should have now. The difference is very significant as I mentioned before.
Sure, but keep in mind that wifi link rates are variable and once the link rate drops below your configured sqm rates bufferbloat will probably show up again.
Let me elaborate, sqm in reality does not know about internet down- and upload directions, all it knows is the directionality of each interface it is instantiated on: for the transmit/TX/egress side, sqm will evaluate the "upload" option in /etc/config/sqm (for the respective interface) and for receive/RX/ingress side it will evaluate the download option (it will instantiate an IFB device to route packets through and instantiate the shaper there, as Linux does not allow to attach qdiscs directly to the ingress side of an interface). Why imply internet down and upload directions in the GUI and the UCI file then? Well, the whole directionality issue is a bit too opaque and complicated for most users, so instead of having to explain these intricacies to every user, we opted for keeping the typical case, SQM operating on the wan interface, somewhat intuitive, accepting that people using SQM on inward facing interfaces will have to research and understand this issue.
What I mentioned NOT set ingress limit is actually for wan, because I found once set that limit, the egress (upload for user) of wlan interface's bufferbloat will become insanely worse to test.
What does that mean? Did you see more bufferbloat with ingress shaping or less? I wonder whether that old router actually is powerful enough to shape your ~700/700 Mbps link?
There is no question that router is not powerful enough to shape the 700Mbps symmetric link. My x86 j1900 gets close to saturated (on one core) shaping my gigabit and it's dramatically more powerful.
@Enig123, I strongly recommend you to move to an x86 router. If you can't afford that, move to a RPi 4 with an extra USB NIC which is cheaper. You can use your D-Link device as a smart switch and WiFi access point.
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.
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.
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.
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.