Sorry? I don't get what you mean.
About the reverting, yeah I am aware and we are actively trying to fix it in another thread.
One of the costly parts of SQM is the traffic shaper we need to gain control over the bottleneck queue, but over WiFi the AP is in control over the queue(s) towards the WiFi-stations, so if we can have fq_codel operate directly on that queue we di not need the costly traffic shaper AND we also deal gracefully with the variable rate nature of WiFi (albeit only in AP to station direction in the other direction the WiFi stations will need to implement something similar in their wifi stacks...). Does this help?
Now I am confused, is your AP already running OpenWrt or not? Or are you working on making revert to Vendor firmware possible so trying out OpenWrt is less risky?
This
Also do you mean, to get a better AP? And yeah, I now get what you mean, since my RPI4 doesn't see the queue from wifi stations, it won't help, a good AP will.
Nah, I just wonder whether your existing AP would not actually work better if you run it under OpenWrt... but I understand that doing that without a way back in case of problems is not attractive. Also if the AP does not belong to you but the ISP reflashing might not be a realistic option...
Neither the wired-only router, nor the AP will see the WiFi upload queues, as these exist within the WiFi stations, but the AP can manage its own queues that handle the stations download traffic much better...
You still might want/need to use a static shaper for the upload direction, but your MIPS CPU is maybe good for 70, maybe 100Mbps traffic shaping in upload direction; then again often there is little upload traffic so not having a shaper might be OK.
Is it frowned upon to ping another user here who has the ax23 on openwrt and ask him for the output for the commands you asked?
I am not the forum admin, but my gut feeling is that politely asking somebody for input/information is actively encouraged.
@frollic
when you reinstall openwrt could you please help me with this, I would greatly appreciated it
@frollic the question is which of the 3 WiFi sqm methods doe the radios of the ax23 support. As far as I can tell it should be all three of them TXQS, AIRTIME_FAIRNESS, and AQL as that seems to be the case for all mt76 devices, but since OpenWrt currently is a one-way street on the AX23 and the OP wants to be cautious here and I do not own an ax23 would you be willing to run the following commands for us:
ubus call system board | grep 'model\|description'
iw list | grep 'Wiphy\|TXQS\|AIRTIME_FAIRNESS\|AQL'
iwinfo | grep 'Hardware:\|PHY name'
these come from @richb-hanover-priv's great thread:
I can do it later, but I just flashed it back to stock, to reproduce the fw version issue we're seeing on the AX23.
You'll probably have to remind me.
2 Likes
Here you go:
root@XXXXXX:~# ubus call system board | grep 'model\|description'
"model": "TP-Link Archer AX23 v1",
"description": "XXXXXXXXX"
root@XXXXXX:~# iw list | grep 'Wiphy\|TXQS\|AIRTIME_FAIRNESS\|AQL'
Wiphy phy1
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
* [ AQL ]: Airtime Queue Limits (AQL)
Wiphy phy0
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
* [ AIRTIME_FAIRNESS ]: airtime fairness scheduling
* [ AQL ]: Airtime Queue Limits (AQL)
root@XXXXXX:~# iwinfo | grep 'Hardware:\|PHY name'
Hardware: 14C3:7915 14C3:7915 [MediaTek MT7915E]
Supports VAPs: yes PHY name: phy0
Hardware: 14C3:7915 14C3:7915 [MediaTek MT7915E]
Supports VAPs: yes PHY name: phy1
This was done on an actual v1, but I double checked and the same output is shown on v1.2, both EU.
2 Likes
Legend 
Thanks!
As expected/hoped for, all the modern things that help making WiFi keep latency lower...
That screenshot is either of a snapshot from before late April or from 23.05 branch - current snapshots should have a list (Disabled, Enabled, Enabled (All CPUs)) instead of a checkbox - "Enabled" is mode 1, "Enabled (All CPUs)" is mode 2.
1 Like
Those numbers seem high according to the SQM wiki:
- Set the Download and Upload speeds to 90% of what you measured in Preparation
297000 is, actually, above the 290 you got on your test run.
e.g. I have 120Mbps down so I set my ingress to 107000
On uploads I get upto 350.
I changed it 330 and it's good since I get no latency. As the wiki suggests to keep jumping it untill you start seeing latency.
I havent.
I don't know about 'jumping' I think it says to continue reducing it until you get the best bufferbloat.
I've read it.
Are you on DSL and getting 390?
This is my current bufferbloat (it goes up and down 5ms, depending on its mood) with packet steering enabled (on a pi4) and the numbers I've already provided.
You really are supposed to start with 10% off and then adjust up if you are still getting bufferbloat or down until you do.
Did you try that?
GPON
yes I started at 250, then moved up using ethernet connection to test.
What throughput did you get with 250?
...and is eth0 your WAN?
I ask because this
config queue eth1'
option enabled '1'
option interface 'eth0'
has confused me.