I've upgraded to v23.05.4 and the speeds went from ~97Mb to ~200Mb+
I've upgraded to v23.05.4 and the speeds went from ~97Mb to ~200Mb+ so big improvement
You may try /usr/share/.. firewall4/templates/zone-mssfix.uc and ucode/fw4.uc from github.com/openwrt/firewall4 master + firewall4/templates/ruleset.uc from https://github.com/openwrt/firewall4/pull/22
Those adjust MTU for offload and shorten default slowpath, so you can have soft offload for all uses without any weird wifi freezes. What you see currently is finally corrected pppoe offload in kernel.
Can you elaborate?
Replace files on device on files updated in firewall4 repo after current firewall4.
On 23.05.3 and non-PPoE, I can get about 250-260 mbps on speedtest.net, which is within range of the practical 300 mbps on this model (also with the updated ucode firewall4 files). CPU usage between 93-95%, mostly softirq as that's from the kernel handling and encrypting/decrypting wireless traffic before/after offloading.
Range does suck though, even at 40 mhz. Within one side of the next room, where the 5ghz signal goes through one wall, I can get speeds of around 100-110 mbps, while at the other side, where the signal goes through two walls (a small toilet between them), it gives 20-30 mbps or worse.
I reckon the OEM firmware was giving larger ranges, but if I recall correctly, I'd it set to auto channel width, so it might have been operating under 20 mhz, which I haven't tested under OpenWrt yet.
SNR at bad side of the room is around 20, with a signal of -90/-95.
I am running the non-ct drivers, but I have tried them both; ct drivers felt less stable, as expected from the wiki note.
P.S. Haven't actually benchmarked with iperf3, as the range is my main concern at the moment. Wired speed maxs out beyond my promised ISP speed (promised 350 mbps, can reach up to 450 mbps depending on time of the day) without saturating the CPU (software flow offload enabled).
softirq is firewall (and soft offload) and qdisc , kworker is either offload (you do not have hardware offload), and irq is hardware acces that does encryption (you have) and d2d DMA aka hw offload (you dont)
note that patches do not change hw offload device set, so in absent support it is likely become slower than sw offload in same device.
Device should be capable of 500/500 duplex or approach 1000 one way (minus some backtalk for acks)
I am no Linux kernel expert, but the majority of the htop bar is magenta during speedtest under wifi, default firewall rules (nothing specific to wlan).
whereas the magenta portion of the bar shows the softirq time
The same behavior does not show under wired ethernet (only a small portion of it is magenta).
I know I don't have hardware flow offload support, which is why I only have software flow offload enabled. Also, as stated above, I can max out my contracted speed on wired without CPU saturation. My main concern currently is range.
Oh, I missed that you mentioned qdisc for softirq too. That's what I meant by "kernel handling wireless traffic".
Can you even bypass qdisc in this case without the wifi driver supporting some kind of offloading though?
Wifi has wmm, theoretically it should be diffserv4 hfsc, implemented in wireless card+driver.
you can set superlight qdisc, latency will increase but it will use minimal CPU
tc qdisc replace dev wan root pfifo_fast
Not sure if this helps or even applies these days or to your issue. But for wifi, i noticed that if you don't set your region, the power setting is pretty diminished. I had forgot to set this, or it got cleared during an upgrade at some point, and after setting the correct region, my signal strength and performance were improved.
I have been through with the power settings already. In fact, on a TL-WR1043ND v3, setting the region correctly (in my case BR) has the driver operate at 14 dBm. Using the driver's default (US), it can operate at 25 dBm, although that does not mean the hardware is capable of operating at such power.
This discrepancy seems to be caused by the ART EEPROM, as the regulatory db shows the same 2.4G rules for BR and US (other than the additional 12 and 13 channels).
country BR: DFS-FCC
(2400 - 2483.5 @ 40), (30)
country US: DFS-FCC
(2400 - 2472 @ 40), (30)
I also couldn't find anything on OpenWrt's ath9k patches that would reduce the power for BR, but not for US.
As for 5G, BR allows for up to 27 dBm in the lower frequencies, which is what I am using in order to increase wavelength.
country BR: DFS-FCC
(5150 - 5250 @ 80), (27), NO-OUTDOOR, AUTO-BW
country US: DFS-FCC
(5150 - 5250 @ 80), (23), AUTO-BW
This one works correctly and the driver is operating at 27 dBm, but as mentioned, this value could be much lower because of the hardware.
(2.4G disabled on this one, ath10k-firmware-qca9888 + kmod-ath10k-smallbuffers, no other 5G APs around)
config wifi-device 'radio0'
option type 'mac80211'
option path 'pci0000:00/0000:00:00.0'
option channel '36'
option band '5g'
option htmode 'VHT80'
option cell_density '0'
option country 'BR'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid '...'
option encryption 'sae-mixed'
option key '...'
There is no driver default of US, ath10k is wrong, check surveys in iw list which takes into account radio abilities.
Driver default as shown in LuCI (option country unset), defaults to US on both of my models.
root@router2:~# iw reg get
global
country US: DFS-FCC
(902 - 904 @ 2), (N/A, 30), (N/A)
(904 - 920 @ 16), (N/A, 30), (N/A)
(920 - 928 @ 8), (N/A, 30), (N/A)
(2400 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 24), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW
(5850 - 5895 @ 40), (N/A, 27), (N/A), NO-OUTDOOR, AUTO-BW, PASSIVE-SCAN
(5925 - 7125 @ 320), (N/A, 12), (N/A), NO-OUTDOOR, PASSIVE-SCAN
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
phy#0
country US: DFS-FCC
(902 - 904 @ 2), (N/A, 30), (N/A)
(904 - 920 @ 16), (N/A, 30), (N/A)
(920 - 928 @ 8), (N/A, 30), (N/A)
(2400 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 24), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW
(5850 - 5895 @ 40), (N/A, 27), (N/A), NO-OUTDOOR, AUTO-BW, PASSIVE-SCAN
(5925 - 7125 @ 320), (N/A, 12), (N/A), NO-OUTDOOR, PASSIVE-SCAN
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
phy#0 is the one used, if global isn't set.
I've already checked the power dBms in iw back then, TL-WR1043ND v3 shows 25 dBm for both BR and US, but the driver seems to cap it at 14 dBm for BR after reading the ART EEPROM.
P.S. this is for ath9k (2.4G), ath10k (5G) works correctly as mentioned in my post.
Nope, thats static text, real thing is
iw reg set BR
iw list | less
As mentioned above, I've done all of that, it's the same rule for both of them (other than the extra two channels).
Here are the driver's reported power with auto or 25 tx_power for ath9k:
TL-WR1043ND v3: (US) 25, (BR) 14
Archer C6 v2 US: (US) 24, (BR) 21
Again, the change only takes place AFTER the driver reads the EEPROM, LuCI, allows me to select up to 25 dBm (which is the max tx_power reported by iw) on both models and on both regions.
iw list reports all channels with factual tx power.
check regdb version insttalled, may need to update...
https://git.kernel.org/pub/scm/linux/kernel/git/wens/wireless-regdb.git/commit/db.txt?id=f29772a6d3670e2af0ebc9a54402ba7cc903aebc
It's not a db problem, I literally went through reading the binary structure with Python to decode both BR and US sections manually.
I believe it's this code in combination with region-specific data read from the EEPROM: https://github.com/openwrt/openwrt/blob/openwrt-23.05/package/kernel/mac80211/patches/ath9k/365-ath9k-adjust-tx-power-reduction-for-US-regulatory-do.patch or this one https://github.com/openwrt/openwrt/blob/openwrt-23.05/package/kernel/mac80211/patches/ath9k/356-Revert-ath9k-interpret-requested-txpower-in-EIRP-dom.patch
If I am correct, for some reason, the EEPROM has different antenna gain values for different regions. My Archer C6 v2 can't operate at 25 dBm under US either, but it can operate at 24 dBm vs 21 dBm on BR.
Check local law text, that chandge may overreach.
Would probably need the help of another brazilian with more knowledge in the subject. From the little research I did back then, I couldn't find anything that would explain this power change between US and BR in the 2.4G range.
It's definitely data from the EEPROM that causes the discrepancy though, whether it's bad data or legislation I can't tell.