stock firmware probably is using 40mhz on 2.4 wifi
check using a wifi scanner app.
I've got a 500 Mbit cable connection which is rocksolid.
Let's take HT40 out and just focus on HT20. Channel 11 has no other wifi around, so I'll stick to that.
On setting: "Up to 347 Mbps" Netgear firmware it's still using HT20 but reaching a solid 45-50 Mbit/s.
Whereas OpenWrt 19.07.2 delivers me very unstable downstream of anything from sub 10 Mbit/s to barely 20 Mbit/s BUT Upstream is often over 30 Mbit/s.
Even if I keep both devices at the exact same spot (0,5m distance), speed may differ greatly from test to test.
Last one was: 15 Mbit/s down,44,4 Mbit/s up... 9,7 down 37 up the one before. Upstream is often reaching acceptable speeds whereas downstream is all over the place. And it's the same for every one of the 3 AP's.
is this the same device?
try using openwrt 18.06
on my tplink atheros i am still using 18.06.4
Yep, same device. Still talking about Netgear R7800. Just tried Netgear firmware again pushing around 100 Mbits down on 2.4 Ghz HT20. Even 2 rooms away I can get ~35 Mbit where OpenWrt barely delivers 3-5 Mbit/s.
Post your settings for the following:
uname -a
cat /etc/config/wireless
Take a look here and see if it’s helpful:
Make sure software flow offloading is turn on in your firewall. Post your results for hardwired versus 5ghz / 80Mhz wide channel for speedtest.net and fast.com.
Firewall service is disabled, this device is a dumb access point. So no NAT. 5 GHz works fine with over 300 Mbit/s down. 2.4 GHz fails to deliver useful speeds.
In a nutshell: This is my R7800 performance when installed in the living room and clients connected, measured from the bedroom about 2-3 meters away with a single wall inbetween.
I did another two iperf tests earlier today between a mac book air and an openwrt r7500v2 2.4 GHz, HT20, channel 6, tx power 30dbm on the AP (I think OSX forces tx power at 20dbm but I can't get it to tell me at the moment).
Both iperf results gave me 100+ mbps down.
EDIT a third iperf test just now
nmba [30] $ !505
iperf -c XX.XX.XX.XX -t60 -i10
------------------------------------------------------------
Client connecting to XX.XX.XX.XX, TCP port 5001
TCP window size: 129 KByte (default)
------------------------------------------------------------
[ 4] local XX.XX.45.128 port 58270 connected with XX.XX.XX.XX port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 133 MBytes 112 Mbits/sec
[ 4] 10.0-20.0 sec 138 MBytes 116 Mbits/sec
[ 4] 20.0-30.0 sec 93.8 MBytes 78.6 Mbits/sec
[ 4] 30.0-40.0 sec 137 MBytes 115 Mbits/sec
[ 4] 40.0-50.0 sec 140 MBytes 117 Mbits/sec
[ 4] 50.0-60.0 sec 140 MBytes 117 Mbits/sec
[ 4] 0.0-60.0 sec 782 MBytes 109 Mbits/sec
nmba [31] $ /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I
agrCtlRSSI: -58
agrExtRSSI: 0
agrCtlNoise: -96
agrExtNoise: 0
state: running
op mode: station
lastTxRate: 144
maxRate: 144
lastAssocStatus: 0
802.11 auth: open
link auth: unknown
BSSID: X:8:5c
SSID: SSIDX24
MCS: 0
channel: 6
The mac book air is more than twice the distance from the AP than ubuntu client I mentioned in the other thread (the ubuntu client tx-power is 15 dbm) and there are two walls obstructing the mac client from the AP.
To help rule out "tx power" issues (either client or AP related), from your openwrt r7800 AP please post the output of:
(please take care to redact any information you are uncomfortable posting, like mac address, ip address, etc from the outputs below)
cat /etc/openwrt_release
iw reg get
iw dev
cat /sys/kernel/debug/ieee80211/phy1/ath10k/fw_stats
cat /sys/kernel/debug/ieee80211/phy1/ath10k/firmware_info
you may have to try a few times to get output from cat ath10k/fw_stats
For comparison, redacted output from my AP here.
Note I am running a "snapshot" build and there may be updates in it (related to ath10k and openwrt's mac80211 implementation) that are not in the openwrt builds you are trying.
Can you compare the tx power you see (both client and AP - the "iw dev" output will tell you on *nix systems) between openwrt and the firmware that give you faster results? (appologies, i don't know how to get this via stock).
Tested right now from my Thinkpad X250 with Intel 7265 AC 2x2 Card. You can see the R7800 blinking in the background. Now even the latency is going mad...
cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='19.07.2'
DISTRIB_REVISION='r10947-65030d81f3'
DISTRIB_TARGET='ipq806x/generic'
DISTRIB_ARCH='arm_cortex-a15_neon-vfpv4'
DISTRIB_DESCRIPTION='OpenWrt 19.07.2 r10947-65030d81f3'
DISTRIB_TAINTS=''
iw reg get
global
country DE: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
(5725 - 5875 @ 80), (N/A, 13), (N/A)
(57000 - 66000 @ 2160), (N/A, 40), (N/A)
phy#1
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
phy#0
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
iw dev
phy#1
Interface wlan1-2
ifindex 15
wdev 0x100000004
addr X
ssid wifi-tor-2-4
type AP
channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
txpower 20.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0
Interface wlan1-1
ifindex 14
wdev 0x100000003
addr X
ssid wifi-gast-2-4
type AP
channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
txpower 20.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0
Interface wlan1
ifindex 12
wdev 0x100000002
addr X
ssid wifi-2-4
type AP
channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
txpower 20.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 5700 0 0 0 0 817569 5700
phy#0
Interface wlan0-2
ifindex 16
wdev 0x4
addr X
ssid wifi-tor-5
type AP
channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz
txpower 20.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0
Interface wlan0-1
ifindex 13
wdev 0x3
addr X
ssid wifi-gast-5
type AP
channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz
txpower 20.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0
Interface wlan0
ifindex 11
wdev 0x2
addr X
ssid wifi-5
type AP
channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz
txpower 20.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 5296 0 0 0 0 758910 5296
cat /sys/kernel/debug/ieee80211/phy1/ath10k/fw_stats
ath10k PDEV stats
=================
Channel noise floor -96
Channel TX power 40
TX frame count 3118731680
RX frame count 2905982108
RX clear count 3148916642
Cycle count 3408251501
PHY error count 4587
RTS bad count 32217
RTS good count 204542
FCS bad count 65535
No beacon count 0
MIB int count 0
ath10k PDEV TX stats
=================
HTT cookies queued 176731
HTT cookies disp. 351716
MSDU queued 203377
MPDU queued 203377
MSDUs dropped 1172
Local enqued 27635
Local freed 27634
HW queued 276838
PPDUs reaped 276836
Num underruns 0
PPDUs cleaned 0
MPDUs requed 74645
Excessive retries 73198
HW rate 1
Sched self triggers 0
Dropped due to SW retries 1019
Illegal rate phy errors 0
Pdev continuous xretry 0
TX timeout 0
PDEV resets 11
PHY underrun 0
MPDU is more than txop limit 0
HW paused 35
Seqs posted 276316
Seqs failed queueing 0
Seqs completed 276314
Seqs restarted 469
MU Seqs posted 0
MPDUs SW flushed 0
MPDUs HW filtered 1670
MPDUs truncated 32417
MPDUs receive no ACK 40834
MPDUs expired 274
ath10k PDEV RX stats
=================
Mid PPDU route change 0
Tot. number of statuses 265
Extra frags on rings 0 499452
Extra frags on rings 1 0
Extra frags on rings 2 18
Extra frags on rings 3 44
MSDUs delivered to HTT 474295
MPDUs delivered to HTT 474294
MSDUs delivered to stack 16489
MPDUs delivered to stack 16489
Oversized AMSUs 0
PHY errors 0
PHY errors drops 4279
MPDU errors (FCS, MIC, ENC) 52606
Num Rx Timeout errors 0
Num Rx Overflow errors 0
DRAM Free 74712
IRAM Free 23220
SRAM Free 14440
ath10k VDEV stats (3)
=================
vdev id 0
ppdu aggr count 2310
ppdu noack 72811
mpdu queued 3662
ppdu nonaggr count 238306
mpdu sw requeued 74365
mpdu success retry 37403
mpdu success multitry 13940
mpdu fail retry 1391
vdev id 1
ppdu aggr count 0
ppdu noack 199
mpdu queued 0
ppdu nonaggr count 276
mpdu sw requeued 145
mpdu success retry 25
mpdu success multitry 9
mpdu fail retry 205
vdev id 2
ppdu aggr count 0
ppdu noack 188
mpdu queued 0
ppdu nonaggr count 266
mpdu sw requeued 135
mpdu success retry 20
mpdu success multitry 6
mpdu fail retry 194
ath10k PEER stats (7)
=================
Peer MAC address X
Peer RSSI 0
Peer TX rate 11000
Peer RX rate 0
Peer RX duration 0
Peer PN 0
Peer MAC address X
Peer RSSI 0
Peer TX rate 0
Peer RX rate 0
Peer RX duration 0
Peer PN 0
Peer MAC address X
Peer RSSI 0
Peer TX rate 0
Peer RX rate 0
Peer RX duration 0
Peer PN 0
Peer MAC address X
Peer RSSI 35
Peer TX rate 72000
Peer RX rate 58000
Peer RX duration 0
Peer PN 0
Peer MAC address X
Peer RSSI 52
Peer TX rate 24000
Peer RX rate 57000
Peer RX duration 0
Peer PN 0
Peer MAC address X
Peer RSSI 35
Peer TX rate 36000
Peer RX rate 48000
Peer RX duration 0
Peer PN 0
Peer MAC address 3X
Peer RSSI 55
Peer TX rate 6000
Peer RX rate 26000
Peer RX duration 0
Peer PN 0
cat /sys/kernel/debug/ieee80211/phy1/ath10k/firmware_info
directory: ath10k/QCA9984/hw1.0
firmware: firmware-5.bin
fwcfg: fwcfg-pci-0001:01:00.0.txt
bus: 0001:01:00.0
features: mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT
version: 10.4b-ct-9984-fW-012-17ba98334
hw_rev: 9984
board: board-2.bin
So it looks like openwrt is setting the AP txpower to 20 dbm (under phy#1, "iw dev" output). That is the correct setting for a place like Germany. However, it is less than what I have (30 dbm, the max allowable by law in my region) which may be a contributing factor to why I can do better than you (for the moment).
The test result in your prior post is odd (especially a ping result of 115 ms). Just to be sure, please confirm you are testing from your client (say the Thinkpad X250) above to your openwrt AP. Testing from your client through your AP to a server outside your home network, even if you have a "fast" isp connection, is not helpful at the moment. For testing the client to AP 2.4 GHz wifi download speed in mbps, use a tool like "iperf -c ap.ip.address" from the client that connects to an "iperf -s" instance running on the openwrt AP. (apologies if you are already doing this... just your results above look like your testing to an external internet speed check website and not your AP).
ping from my client to my AP looks like:
(p382.mkl) [89] $ ping ap.ip.address
PING ap.ip.address (ap.ip.address) 56(84) bytes of data.
64 bytes from ap.ip.address: icmp_seq=1 ttl=64 time=1.95 ms
64 bytes from ap.ip.address: icmp_seq=2 ttl=64 time=2.18 ms
64 bytes from ap.ip.address: icmp_seq=3 ttl=64 time=1.46 ms
Lastly, you get faster "results" with the same client using a stock firmware than you do with openwrt on 2.4 GHz wifi. To rule out the possibility that the stock firmware is setting the txpower too high for a region like Germany (say making it 30 dbm like mine instead of the proper 20 dbm for Germany) you have to check what it is on the stock firmware. I can't help with that tho.
I've already tried iperf, believe me: speedtest.net equals the iperf results. I've got a pretty good 500 Mbit connection so speedtest.net is good enough to test wifi speed.
But here we go, 5 Ghz HT40 maxes out at a rocksolid 200 Mbit/s:
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 24.9 MBytes 207 Mbits/sec
[ 4] 1.01-2.00 sec 24.2 MBytes 206 Mbits/sec
[ 4] 2.00-3.00 sec 24.0 MBytes 201 Mbits/sec
[ 4] 3.00-4.00 sec 24.0 MBytes 202 Mbits/sec
[ 4] 4.00-5.01 sec 23.6 MBytes 197 Mbits/sec
[ 4] 5.01-6.00 sec 24.9 MBytes 209 Mbits/sec
[ 4] 6.00-7.00 sec 25.0 MBytes 210 Mbits/sec
[ 4] 7.00-8.00 sec 24.4 MBytes 204 Mbits/sec
[ 4] 8.00-9.01 sec 24.9 MBytes 208 Mbits/sec
[ 4] 9.01-10.00 sec 23.9 MBytes 202 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 244 MBytes 204 Mbits/sec sender
[ 4] 0.00-10.00 sec 244 MBytes 204 Mbits/sec receiver
And this is the 2.4 GHz radio:
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 640 KBytes 5.19 Mbits/sec
[ 4] 1.01-2.01 sec 1.25 MBytes 10.5 Mbits/sec
[ 4] 2.01-3.01 sec 1.00 MBytes 8.39 Mbits/sec
[ 4] 3.01-4.01 sec 640 KBytes 5.24 Mbits/sec
[ 4] 4.01-5.01 sec 640 KBytes 5.24 Mbits/sec
[ 4] 5.01-6.01 sec 896 KBytes 7.34 Mbits/sec
[ 4] 6.01-7.01 sec 640 KBytes 5.24 Mbits/sec
[ 4] 7.01-8.01 sec 1.25 MBytes 10.5 Mbits/sec
[ 4] 8.01-9.01 sec 1.62 MBytes 13.6 Mbits/sec
[ 4] 9.01-10.01 sec 768 KBytes 6.29 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.01 sec 9.25 MBytes 7.75 Mbits/sec sender
[ 4] 0.00-10.01 sec 9.25 MBytes 7.75 Mbits/sec receiver
I tried a few times, very unstable, just look at this, from 2 to 40 Mbit/s:
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 4.50 MBytes 37.7 Mbits/sec
[ 4] 1.00-2.01 sec 4.12 MBytes 34.3 Mbits/sec
[ 4] 2.01-3.01 sec 4.38 MBytes 36.8 Mbits/sec
[ 4] 3.01-4.01 sec 4.88 MBytes 40.8 Mbits/sec
[ 4] 4.01-5.01 sec 3.25 MBytes 27.2 Mbits/sec
[ 4] 5.01-6.01 sec 2.38 MBytes 19.9 Mbits/sec
[ 4] 6.01-7.01 sec 256 KBytes 2.09 Mbits/sec
[ 4] 7.01-8.02 sec 896 KBytes 7.33 Mbits/sec
[ 4] 8.02-9.00 sec 2.00 MBytes 17.0 Mbits/sec
[ 4] 9.00-10.01 sec 2.50 MBytes 20.8 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.01 sec 29.1 MBytes 24.4 Mbits/sec sender
[ 4] 0.00-10.01 sec 29.0 MBytes 24.3 Mbits/sec receiver
Sometimes it's a little bit more "ok":
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 4.75 MBytes 39.3 Mbits/sec
[ 4] 1.01-2.01 sec 3.25 MBytes 27.3 Mbits/sec
[ 4] 2.01-3.00 sec 3.50 MBytes 29.7 Mbits/sec
[ 4] 3.00-4.00 sec 3.75 MBytes 31.4 Mbits/sec
[ 4] 4.00-5.00 sec 4.00 MBytes 33.6 Mbits/sec
[ 4] 5.00-6.00 sec 4.88 MBytes 41.0 Mbits/sec
[ 4] 6.00-7.00 sec 2.00 MBytes 16.8 Mbits/sec
[ 4] 7.00-8.00 sec 4.38 MBytes 36.7 Mbits/sec
[ 4] 8.00-9.00 sec 4.12 MBytes 34.6 Mbits/sec
[ 4] 9.00-10.01 sec 2.50 MBytes 20.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.01 sec 37.1 MBytes 31.1 Mbits/sec sender
[ 4] 0.00-10.01 sec 37.1 MBytes 31.1 Mbits/sec receiver
Oh, and btw, I don't think raising the TX power any higher than 100mW will help if I'm in front of the AP, it's also not alloweed here in Germany.
Thank you for confirming with the iperf results between the client and AP. My perception is that you are an "advanced" user but the symptoms seem so odd that I wanted to confirm.
tl;dr try
- disconnecting the AP from your downstream network and repeat the iperf/ping tests (to show how the downstream network - i.e. the router, isp modem, and internet - affects these symptoms).
- reproduce the symptoms on a "master" build (also connected to/disconnected from your downstream network).
- reset to defaults the AP configuration and simplify the configuration to make only a connection to the external internet via one SSID on 2.4 wifi only. I.e. no (or minimal) vlan's, no lan except to connect to the router, no vdev's, one SSID, turn off 5 GHz. Test and if you don't see symptoms, then incrementally add configuration complexity back until the symptoms manifest.
You have not yet posted your /etc/config/wireless (others may request /etc/config/network as well). Be careful to redact passwords and ip address from these files before posting. That said, its hard to decipher a complex set up like you have - if possible, simplify it as much as you can and still reproduce the symptoms.
There are a few more things you can try if you still have the patience to do so. Somehow I can't seem to write it without embedding some observations and advice about how to do it - sorry for that.
If the end result of this thread is a bug report, then you want to be able to describe and isolate the symptoms in a way that the openwrt devs can reproduce it. Demonstrating the affect of the down stream network (or lack there of) and not presenting the symptoms solely as a difference between non-openwrt and openwrt firmware is likely necessary to get any attention on the bug report (you should, however, mention these as they are material to the problem).
I agree about raising the TX power beyond the regulatory limit. You should not have this issue with 2.4 wifi at 20 dbm that close to your AP (and my results help to show that).
As you may be aware, there is another thread discussing a similar issue here. Note that the build is the same as you posted above from the "cat /etc/openwrt_release" (DISTRIB_REVISION='r10947-65030d81f3'). Link the other forum thread and any other directly relevant forum post in addition to this thread if/when you make a bug report (i.e. its not just you).
Its possible that this issue has already been fixed but not (effectively) communicated. One way to tell is try a "snapshot" build. @hnyman's "master" build (I suggest "ath10k-ct") is a good choice. @hnyman has a lot of credibility both on these forums and with the devs. If the symptoms are not present on a master build, then there is little more you can do (other than complaining about it if it is not fixed in the next stable build).
FWIW I am using ath10k-firmware-ct-full-htt (likely @hnyman's builds are not the htt ones). That should not matter, you can reproduce this on non ath10k devices.
Clearly and concisely as possible communicate all builds and devices you tried and your configuration (i.e. build info from /etc/openwrt_release, /etc/config/network, /etc/config/wireless, etc) in your bug report along with what symptoms you observed for each build. In this case your iperf/ping results between a client and the AP on 2.4 vs 5 GHz. Ideally, disconnect the AP from the downstream network unless that is necessary to demonstrate the issue. Consolidate and briefly mention your attempts to consider issues like distance from the AP, obstructions, wifi interference from neighbors, clients effects (link back to these threads for reference).
The other thing you can do is demonstrate that this issue does not exist on an older openwrt build. Show that and that the symptoms are still present in "master" (both in way that a dev can reproduce it) then you have done everything short of becoming a dev yourself to help the community fix it.
My observation is that many in the openwrt community are (mostly) indifferent to comparisons to stock firmware. i.e. If you focus on that comparison, its likely you will get a response like "if you like stock use it (and don't bother us about how you are not satisfied with openwrt)"
With your environment there are several things creating scenarios that might be sapping your bandwidth.
- With three virtual APs on each band you are creating extra overhead. Each virtual AP acts like a real AP, the radios have to send extra management frame and deconflict between the virtual APs. Depending on your environment you could be seeing penalties of 10%+ (maybe much more depending on your clients and the below reasons). Good discussion here:
- if you have busy clients on the network (ex:torrenting or streaming), lots of clients, any 2.4ghz interference from neighbors / other devices - your device will have to wait more:
https://www.duckware.com/tech/wifi-in-the-us.html#wifispeeds
- very few clients truly support 40mhz wide 2.4 channels in real world environments. On the client side they will revert to 20mhz due to all the above two reasons. See here for a quick discussion on the trick that is the 2.4ghz channel:
https://www.duckware.com/tech/wifi-in-the-us.html#wifi4
When doing synthetic benchmarks for wifi turn off your extra virtual APs, quiet down the clients on your network, and pick channels different from any neighbors. Wifi can vary so drastically depending on load and setup that you want something you can replicate. You should be getting rates in the 50mbps range with a 2x2 client 20mhz on 2.4ghz (with a typical PHY of ~72) You should be in the 400mbps range consistently with a 2x2 client 80mhz width on 5ghz.
The 2.4ghz band is terrible and I don’t recommend it for phones. 5ghz is a better place to be. Is it possible to only use two Virtual APs per band or better yet just use the physical interface, no virtuals?
That's a good observation and suggestion.
the output from ath10k/fw_stats shows he had 7 clients connected to the AP at the time but they look a bit odd if you compare them to my output - I'm not sure if this is due to redacting some info tho
I MAY have found the cause of my problems... Let me experiment a bit and I will explain later. It seems to be some "external" problem, but I don't understand why the Netgear firmware dosn't show the same behavior if I'm right with my guess.
This would also explain why the problems exist on ALL of my Devices (Linksys, Netgear, TP-Link) since around 2-3 years...
I'm now up to a stable ~45-60 Mbit's on 2.4 GHz.
Looks A LOT better now...
[ 4] local 192.168.1.96 port 57610 connected to 192.168.1.27 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 8.62 MBytes 71.8 Mbits/sec
[ 4] 1.01-2.00 sec 8.50 MBytes 71.5 Mbits/sec
[ 4] 2.00-3.01 sec 5.50 MBytes 46.0 Mbits/sec
[ 4] 3.01-4.01 sec 8.88 MBytes 74.4 Mbits/sec
[ 4] 4.01-5.01 sec 8.75 MBytes 73.0 Mbits/sec
[ 4] 5.01-6.01 sec 8.50 MBytes 71.3 Mbits/sec
[ 4] 6.01-7.01 sec 8.50 MBytes 71.3 Mbits/sec
[ 4] 7.01-8.02 sec 6.00 MBytes 49.8 Mbits/sec
[ 4] 8.02-9.00 sec 8.88 MBytes 76.1 Mbits/sec
[ 4] 9.00-10.01 sec 8.25 MBytes 68.3 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.01 sec 80.4 MBytes 67.3 Mbits/sec sender
[ 4] 0.00-10.01 sec 80.4 MBytes 67.3 Mbits/sec receiver
And what was the reason for your bad performance?