No, it is all gonna stay the same including master and the next release.
920mbps via wifi means your are using an 160mhz channel with your 2x2 AX200.
550mbps makes sense for a 2x2 80Mhz OpenWRT setup. When comparing firmware with near double speed difference - make sure you fully posting your settings and testing methods. What does it look like when you use a 160 MHz channel on OpenWRT?
@ACwifidude : I was using 160 MHz in both cases, CPU was fully loaded with OpenWRT and that's probably the limiting factor
Check your country code and channel selection - makes a big difference for OpenWRT (select something legal).
160mhz in the US is doable selecting 100 for the channel, waiting a couple minutes for the router to scan for radar interference then running testing:
Run your CPU at performance governor or more aggressive ondemand settings. Turn on software offloading and turn off SQM.
I'm located in France and specified the right country code for that.
I switched back to stock firmware at the moment, but my tests were performed with performance governor, flow offloading enabled. Apart from that I was close to a default configuration, I did not touch SQM, I don't know if it's enabled ou disabled by default?
SQM is disabled by default.
Doesn’t sound like your adapter was truly connected at 160mhz. EU probably prefers lower channels I’d guess. I’d run the latest master build with the latest CT drivers to get the best results.
Post your wifi configuration and adapter phy rate if you decide to test again. 160mhz should give you high 800mbps / low 900mbps.
I actually got worse performance with master build, I could not get 160 MHz working, giving ~ 300 to 400 mbits download / 450~500 mbits upload (better in upload):
wlan0 ESSID: "NETGEAR56-5G"
Access Point: 8C:3B:AD:2D:1D:2B
Mode: Master Channel: 44 (5.220 GHz)
Tx-Power: 23 dBm Link Quality: 52/70
Signal: -58 dBm Noise: -103 dBm
Bit Rate: 396.6 MBit/s
Encryption: WPA2 PSK (CCMP)
Type: nl80211 HW Mode(s): 802.11nac
Hardware: 168C:0046 168C:CAFE [Qualcomm Atheros QCA9984]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy0
Back to 19.07.3, I have the same numbers as 19.07.2 ~550 mbits down / 350 to 400 upload:
wlan0 ESSID: "NETGEAR56-5G"
Access Point: 8C:3B:AD:2D:1D:2B
Mode: Master Channel: 44 (5.220 GHz)
Tx-Power: 23 dBm Link Quality: 65/70
Signal: -48 dBm Noise: -103 dBm
Bit Rate: 783.0 MBit/s
Encryption: WPA2 PSK (CCMP)
Type: nl80211 HW Mode(s): 802.11nac
Hardware: 168C:0046 168C:CAFE [Qualcomm Atheros QCA9984]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy0
My AC wireless config:
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11a'
option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
option htmode 'VHT160'
option channel '44'
option country 'FR'
That's the same channel as the one I was using with the stock firmware giving a big 900 mbits down / 400 mbits up. I've tried to play with channels without success. One thing I have noticed is about power, on the client side I can see:
OpenWRT 19.07.3:
Interface wlan0
ifindex 4
wdev 0x1
addr 24:41:8c:e1:aa:a0
ssid NETGEAR56-5G
type managed
wiphy 0
channel 44 (5220 MHz), width: 160 MHz, center1: 5250 MHz
txpower 20.00 dBm
Netgear 1.0.2.68:
Interface wlan0
ifindex 4
wdev 0x1
addr 24:41:8c:e1:aa:a0
ssid NETGEAR56-5G
type managed
wiphy 0
channel 44 (5220 MHz), width: 160 MHz, center1: 5250 MHz
txpower 22.00 dBm
I've seen in dmesg of the client that it's negotiating more power with stock firmware than with OpenWRT firmware:
wlan0: Limiting TX power to 20 (23 - 3) dBm as advertised by 8c:3b:ad:2d:1d:2b
CH 44 is no valid 160Mhz channel and your bitrate confirms it, only CH100 is valid for 160Mhz. Netgear probably uses 80+80, you can't currently configure this in openwrt webif.
I switched to channel 100:
wlan0 ESSID: "NETGEAR56-5G"
Access Point: 8C:3B:AD:2D:1D:2B
Mode: Master Channel: 100 (5.500 GHz)
Tx-Power: 26 dBm Link Quality: 55/70
Signal: -55 dBm Noise: -97 dBm
Bit Rate: 1560.0 MBit/s
Encryption: WPA2 PSK (CCMP)
Type: nl80211 HW Mode(s): 802.11nac
Hardware: 168C:0046 168C:CAFE [Qualcomm Atheros QCA9984]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy0
The max download speed is still stuck at 550 mbits, as I said in my first comment, I don't really see how to get more without finding a way to ease CPU job, as it is fully loaded at this speed, even without SQM and with performance governor.
That bitrate looks much better.
How are you measuring speed? If you have gigabit wan I’d try fast.com or speedtest.net. Otherwise post your iperf between two computers with the router in between (don’t use the router as the iperf server, you’ll saturate the CPU there for sure). I’d hardwire a computer to one of the LAN ports, run iperf in server mode and see what you get.
I have 1 gbits down / 800 mbits up, reliable, at least for download, I'm sure that my download speed is not limited by my internet access when I have ~600 mbits. I was using equivalents of fast.com or speedtest.net
fast.com: 580 mbits down / 260 mbits up
speedtest.net : 523 mbits down / 320 mbits up
degrouptest.com (french one) : 540 mbits down / 225 mbits up
With stock firmware, I was able to get a big 900 mbits at each attempt with the same tests
Interesting. Running master?
Any other APs, radar, or other devices that use 5ghz that could be causing interference?
Any other programs enabled (turn off adblocker, and everything that could be robbing small bits of performance).
You are already running performance governor. I’d try turning on Irq balance and global packet steering.
uci set network.globals.packet_steering=1; uci commit network
uci set irqbalance.irqbalance.enabled=1; uci commit
550mbps might be full speed with 160mhz wide channel wifi if the above don’t apply. Those two proprietary software driven 800mhz NSS cores probably are making the difference between stock firmware and OpenWRT with NAT + wifi running at full speed.
Well I'm on kongs r7800 trunk build and I get 800Mbps. Not sure if it's settings, or radio fw difference.
Bitrate says: 1733.3 Mbit/s, 160 MHz, VHT-MCS 9, VHT-NSS 2, Short GI
19.07.3, performances are actually lower with master build ( less than 400 mbits download )
I switched off my other 5Ghz AP (actually it did not change the performances when I switched it off). There is possibly my neighbour AP but anyway, if there is something affecting affecting wireless performances here, it should affect performances with stock firmware as well. The measures I'm getting are perfectly repeatable at any time. I doubt that the environment is responsible of lower performances with OpenWRT firmware compared to stock.
The second parameter does not seem to be recognized? (uci: Entry not found)
I gave a very brief test to ddwrt, I was getting the same numbers as OpenWRT ~ 550 mbits
You need to install irqbalance first.
That’s interesting. He has several scripts and unique packages to change performance behavior:
http://www.desipro.de/openwrt/sources/
Don’t know which tweaks are getting you that much more throughput - someone more fluent would have to see the difference.
Not ddwrt, kong openwrt trunk with kernel 5.4. Only thing I changed is the option Packet Steering enabled. H 100 + 160Mhz + US, everything else is pretty much on default.
So... I redid tests with packet steering and irqbalance
With 19.07.3 : activating irqbalance bandwidth drops from 550 mbits down / 350-400 mbits down to 400 mbits down / 450-500 mbits up
With master snapshot: I can't get channel working at 160MHz anymore, rate drop to 360 mbits. Consequently my bandwidth is about 300 mbits down / 300 mbits up without irqbalance and 600 mbits down / 450-500 mbits up with irqbalance.
I've tried several master builds (kong, hnyman) and they all give the same numbers, I can't get the same phy rate as 19.07.3
Edit: forgot to mention that with 19.07.3 the limiting factor was the cpu usage, I had one cpu at 100% and the other one at 60% without irqbalance, with irqbalance only one cpu was 100% loaded, the other one nothing.
With master, both cpu are around 70-80%, the limiting factor seems to be phy rate.
Are you testing with the ath10k or ath10k-ct driver/firmware? If you're using ath10k-ct, would you mind downloading the latest ath10k-ct beta firmware and retrying your tests with a snapshot build?
To do so:
wget https://www.candelatech.com/downloads/ath10k-9984-10-4b/ath10k-fw-beta/firmware-5-ct-htt-mgt-community.bin
[ -f /lib/firmware/ath10k/QCA9984/hw1.0/firmware-5.bin ] && mv firmware-5-ct-htt-mgt-community.bin /lib/firmware/ath10k/QCA9984/hw1.0/firmware-5.bin
[ -f /lib/firmware/ath10k/QCA9984/hw1.0/ct-firmware-5.bin ] && mv firmware-5-ct-htt-mgt-community.bin /lib/firmware/ath10k/QCA9984/hw1.0/ct-firmware-5.bin
Would love to see if it performs better or worse for you.
1 Like
I was using the default one with snapshot builds, which is the latest CT driver, non htt-mgt. I've just tried the latest beta, with or without htt-mgt, it does not change the numbers regarding transfer rates.