Ansuel
7610
most of 5ghz chan require dfs scan and that would take even 10minutes so... this is probably the reason it didn't work... still you can totally use chan 36 for 160mhz that should not have the dfs limitation
Been running for ~24 hrs and the 2.4G radio has not not been particularly stable:
[79707.892162] ath10k_pci 0000:01:00.0: rts threshold -1
[79707.907903] ath10k_pci 0000:01:00.0: failed to transmit packet, dropping: -19
[79707.907960] ath10k_pci 0000:01:00.0: failed to submit frame: -19
[79707.914054] ath10k_pci 0000:01:00.0: failed to push frame: -19
[79707.920170] ath10k_pci 0000:01:00.0: failed to transmit packet, dropping: -19
[79707.925755] ath10k_pci 0000:01:00.0: failed to submit frame: -19
[79707.932971] ath10k_pci 0000:01:00.0: failed to push frame: -19
[79707.939082] ath10k_pci 0000:01:00.0: failed to transmit packet, dropping: -19
[79707.944677] ath10k_pci 0000:01:00.0: failed to submit frame: -19
[79707.951908] ath10k_pci 0000:01:00.0: failed to push frame: -19
[79707.958037] ath10k_pci 0000:01:00.0: device successfully recovered
[79707.962964] ath10k_pci 0000:01:00.0: failed to transmit packet, dropping: -19
[79707.969822] ath10k_pci 0000:01:00.0: failed to submit frame: -19
[79707.977017] ath10k_pci 0000:01:00.0: failed to push frame: -19
[79708.336730] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped old beacon
<snip>above repeated a futher 79 times</snip>
[79716.949190] ath10k_pci 0000:01:00.0: Cannot communicate with firmware, previous wmi cmds: 40859:7940914 36904:7940914 36867:7940914 36891:7940726, jiffies: 4302908512, attempting restart restart firmware, dev-flags: 0 x142
[79716.949285] ath10k_pci 0000:01:00.0: failed to send wmi nop: -11
[79716.967876] ath10k_pci 0000:01:00.0: could not request stats (type -268435456 ret -108 specifier 1)
[79717.029177] ath10k_pci 0000:01:00.0: removing peer, cleanup-all, deleting: peer 000000007f3474f3 vdev: 0 addr: 54:ef:44:24:eb:05
<snip>above repeated for multiple peers</snip>
[79717.330938] ieee80211 phy0: Hardware restart was requested
[79717.331054] ath10k_pci 0000:01:00.0: failed to recalculate rts/cts prot for vdev 0: -108
[79717.335336] ath10k_pci 0000:01:00.0: failed to disassociate station: 58:b6:23:89:64:35 vdev 0: -108
[79717.343700] ath10k_pci 0000:01:00.0: failed to delete peer 58:b6:23:89:64:35 for vdev 0: -108
[79717.352686] ath10k_pci 0000:01:00.0: failed to recalculate rts/cts prot for vdev 0: -108
[79717.361047] ath10k_pci 0000:01:00.0: failed to disassociate station: 58:b6:23:89:64:35 vdev 0: -108
[79718.351075] ath10k_pci 0000:01:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256
[79718.357627] ath10k_pci 0000:01:00.0: wmi print 'P 128 V 8 T 410'
[79718.357691] ath10k_pci 0000:01:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0 ct-sta: 0'
[79718.364318] ath10k_pci 0000:01:00.0: wmi print 'alloc rem: 25560 iram: 24780'
[79718.409435] ath10k_pci 0000:01:00.0: pdev param 0 not supported by firmware
Ansuel
7613
what are you doing with that poor router o.o
Not even asking it to route! 
2x .1q interfaces on eth0
2x bd (for each .1q interface)
2x "interfaces" (for each bd, one unmanaged, one static - just for management)
3x SSIDs (2.4 + 5 for "lan" and iot radio for "iot")
dchard
7615
Correct me if I am wrong, but that is the IoT radio, not the main 2.4G one as that is also driven by ath11k, not by ath10k. Given the fact how crappy the isolation would be on the board, I would definitely not use the IoT radio in these routers for sure, only creates interference. The whole concept is flawed, as for IoT devices you dont need a separate radio anyway. A normal N/AX configured radio on 2.4G will be efficient enough.
Now that we are talking about it: is it possible to disable the B and G variants on the 2.4G radio, or N on the 5G radio by any chance?
@Baden this is a dev topic, we are not here to tell you how 802.11 operates on a basic level. Complaining about things not working without merit is frankly getting annoying, although l must admit that lately the overall situation in the topic seems to be improved. I would advice you to read a bit about the technology before you issue complaints.
I have to report very inconsistent speeds far from the router. Sometimes doing an speed test I get like 250mb/s in the first 3 seconds and then drops to 100mb/s. And sometimes do not get more than 20mb/s in the same place with the same device that got 130mb/s for some reason. I think is because the router dynamically changes the with of the signal, sometimes I get 20MHz in devices that can use 80Mhz but I'm not sure.
Does someone have a similar problem?
Edit:
The same hardware in the same place (a router acting as a repeater as wds-client) was getting me 200 mb/s with a xiaomi 4a Gigabit that had a 5Ghz radio, in the same place that now gets 250mb/s the first 2 seconds and then drops to 120mb/s with the ax3600.
How can I debug this? Can I configure something to get better performance? software offloading is enabled and packet steering is enabled.
dchard
7617
You sure your client device does not switched back to the 2.4G radio? Sound like that is the case. Most of the devices can only display the broadcast channel bandiwdth: for example my phone does display the 160MHz channel, although it can only use 80MHz max. On the router side, you can see that the max channel width is 80MHz.
If you are referring to this:
That happens when the device is in idle mode. To save power when there is very low traffic or no traffic at all, the device switches back to these low power states. In AX mode it is possible for the AP to select smaller than full channel bandwidth if the power budget is not enough (coverage edge) or the required speed does not justify this, but I am not sure if that will be indicated here, as every scheduling decision can change this dynamically practically every millisecond based on the traffic needs.
Ansuel
7618
@dchard didn't even notice it was ath10k... then it's probably broken firmware
Baden
7619
i know the technical details about 802.11 but there where some releases, which caused problemes with 5 GHZ wifi - other useres reported this issue too. perhaps therefore i was to impatient and did not wait long enough.
I only use the ax radio so that's impossible.
Yep, that what I meant.
Is it maybe something to do with the protocols that is using (the HE-MCS 9, HE-NSS 2...) I don't know what anything of that means, but maybe it is related to my wildly unstable speeds? All my devices have the short GI enabled despite being in in different stances of my house. But I'm only blindly guessing.
For some reason my wan interface is going down at random times.
Tue Jun 14 12:37:31 2022 daemon.notice netifd: Network device 'eth0' link is down
Tue Jun 14 12:37:31 2022 daemon.notice netifd: 8021q 'eth0.832' link is down
Tue Jun 14 12:37:31 2022 daemon.notice netifd: Interface 'wan' has link connectivity loss
Tue Jun 14 12:37:31 2022 daemon.notice netifd: Interface 'wan6' has link connectivity loss
Tue Jun 14 12:37:31 2022 kern.info kernel: [60461.710647] nss-dp 3a001200.dp2 eth0: PHY Link is down
Tue Jun 14 12:37:31 2022 daemon.notice netifd: wan (2657): udhcpc: received SIGTERM
Tue Jun 14 12:37:31 2022 daemon.notice netifd: wan (2657): udhcpc: unicasting a release of 89.129.125.69 to 81.52.127.248
Tue Jun 14 12:37:31 2022 daemon.notice netifd: wan (2657): udhcpc: sending release
Tue Jun 14 12:37:31 2022 daemon.notice netifd: wan (2657): udhcpc: entering released state
Tue Jun 14 12:37:31 2022 daemon.notice netifd: wan (2657): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "wan" } (Permission denied)
Tue Jun 14 12:37:31 2022 daemon.notice netifd: Interface 'wan' is now down
Tue Jun 14 12:37:31 2022 daemon.notice netifd: Interface 'wan' is disabled
Tue Jun 14 12:37:31 2022 daemon.notice netifd: Interface 'wan6' is disabled
Tue Jun 14 12:37:31 2022 daemon.notice netifd: Interface 'wan' is enabled
Tue Jun 14 12:37:31 2022 daemon.notice netifd: Interface 'wan6' is enabled
.............
Tue Jun 14 12:38:10 2022 daemon.notice netifd: 8021q 'eth0.832' link is down
Tue Jun 14 12:38:10 2022 daemon.notice netifd: Interface 'wan' has link connectivity loss
Tue Jun 14 12:38:10 2022 daemon.notice netifd: Interface 'wan6' has link connectivity loss
Tue Jun 14 12:38:10 2022 kern.info kernel: [60500.350685] nss-dp 3a001200.dp2 eth0: PHY Link is down
Tue Jun 14 12:38:10 2022 daemon.notice netifd: wan (14309): udhcpc: received SIGTERM
Tue Jun 14 12:38:10 2022 daemon.notice netifd: wan (14309): udhcpc: entering released state
Tue Jun 14 12:38:10 2022 daemon.notice netifd: wan (14309): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "wan" } (Permission denied)
Tue Jun 14 12:38:10 2022 daemon.notice netifd: Interface 'wan' is now down
Tue Jun 14 12:38:10 2022 daemon.notice netifd: Interface 'wan' is disabled
Tue Jun 14 12:38:10 2022 daemon.notice netifd: Interface 'wan6' is disabled
Tue Jun 14 12:38:10 2022 daemon.notice netifd: Interface 'wan' is enabled
Tue Jun 14 12:38:10 2022 daemon.notice netifd: Interface 'wan6' is enabled
As you can see I have a vlan required by my ISP to get internet
Ansuel
7622
? ax is also supported for 2.4 so....
Then I have to specify that I'm using the generic 802.11nacax radio with only 1 wireless network in ax mode and 160 width.
Good catch! Not sure how I missed that - you are indeed correct, I had them the wrong way around. 
Ditched the IoT radio and just created another vap under the main radio.
1 Like
dchard
7626
HE-MCS 9, HE-NSS 2
MCS9 is the coding rate (pretty good), NSS 2 means 2x2 MIMO is encoded. If you see NSS 1, that means either the client is not supporting 2 receive antennas, or the radio environment is not suitable for MIMO precoding. Neither of these indicates the scheduled bandwidth (channel bandwidth I mean). If you would be close to the coverage edge, you should see lower MCS... And they improved AX from that point of view. I might turn on the 2.4G radio in AX mode with fast roaming just to see that your client roams to the 2.4 radio in the same spot and this is an actual coverage issue.
1 Like
Thanks for the explanation! All my clients also use Short GI, idk if it is a good thing.
The issue that I have is shown here:
Test-A:
Test-B
As you can see, both test were taking like 15 min apart and yet, they show a lot of differences.
The inconsistent speed that i have been talking about is better appreciated in test-A, 10 & 25 mb download size where some of the data were downloaded at 125mb/s and others at 320mb/s in the same test, and yet 15 min later the problem is no longer there.
The device is a router in bridged mode, nailed on to the wall so movement is not a variable.
The page is https://speed.cloudflare.com/ if you want to check it out.
Crect
7628
With build from a few months ago
try https://fast.com/ i get 1gpps here ... using your cloudfare link i get 506mbps
also other considerations is your isp ... you are sharing a link with others etc
