Overall slow 2.4 GHz WiFi on OpenWrt devices

cyablo · May 14, 2020, 6:38pm

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

anon98444528 · May 14, 2020, 7:26pm

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.

cyablo · May 14, 2020, 9:13pm

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

cyablo · May 14, 2020, 9:17pm

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

cyablo · May 14, 2020, 9:20pm

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.

anon98444528 · May 15, 2020, 12:08am

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)"

ACwifidude · May 15, 2020, 1:37am

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?

anon98444528 · May 15, 2020, 1:44am

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

cyablo · May 15, 2020, 6:58am

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.

cyablo · May 15, 2020, 7:26am

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

juppin · May 15, 2020, 7:32am

And what was the reason for your bad performance?

tmomas · May 15, 2020, 7:59am

Please use the "Preformatted text </>" button for logs, scripts, configs and general console output.

Please edit your postings accordingly. Thank you!

cyablo · May 15, 2020, 8:03am

It looks like the babypone with camera made by "Audioline" we've got since about 3 years. OpenWrt doesn't show any high noise level and the problem was present on all channels, so I didn't expect it to be the camera.

Oddly enough the netgear factory firmware handles the interferences very well. I don't know what kind of 'magic' they do. This is still a bit slower than factory firmware with over 90 Mbit/s, but I'm fine with that.:

[  4] local 192.168.1.96 port 59443 connected to 192.168.1.27 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.02   sec  9.75 MBytes  80.4 Mbits/sec
[  4]   1.02-2.01   sec  9.62 MBytes  81.2 Mbits/sec
[  4]   2.01-3.01   sec  10.1 MBytes  85.4 Mbits/sec
[  4]   3.01-4.00   sec  10.0 MBytes  84.4 Mbits/sec
[  4]   4.00-5.00   sec  6.38 MBytes  53.3 Mbits/sec
[  4]   5.00-6.01   sec  7.75 MBytes  64.6 Mbits/sec
[  4]   6.01-7.00   sec  8.62 MBytes  73.1 Mbits/sec
[  4]   7.00-8.01   sec  8.25 MBytes  68.4 Mbits/sec
[  4]   8.01-9.00   sec  9.12 MBytes  77.5 Mbits/sec
[  4]   9.00-10.01  sec  9.62 MBytes  80.4 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.01  sec  89.2 MBytes  74.8 Mbits/sec                  sender
[  4]   0.00-10.01  sec  89.2 MBytes  74.8 Mbits/sec                  receiver

cyablo · May 15, 2020, 8:17am

Sure, done.

cyablo · May 15, 2020, 9:07am

I have to admit, I feel a little like an idiot right now. I have always guessed OpenWrt to be the problem and the good stock firmware performance also seemed to support this. There was no high noise level and the wifi channel also didn't matter. So I never thought about somethng like this.

The good test results of nmrh made me rethink about the cause of my slowdowns.

But that also explains the the slow wifi test in the basement. This damn baby monitor can reach through the whole house while I need two access points inside to get an acceptable wifi coverage.

Sadly I have no equipment to look at the 2.4 GHz spectrum in a more raw way, my cheap realtek software definied radio only goes up to 2.1 GHz. But this thing must use some massive bandwidth and transmit power to interfere like this.

Thanks to all who tried to help me out!

anon98444528 · May 15, 2020, 10:00am

Glad you found the cause. I started to feel like an idiot myself once I saw you had 3 vdev's. As I said above and I still think it, you seem "advanced."

cyablo · May 15, 2020, 11:22am

The vlan's? That's because I work as a sysadmin and I'm used to encapsulate every department into it's own vlan and firewall them from each other. So it's more a "because I can" thing.

My other AP even has 4 wifi's per band, it has an aditional WDS wifi for bridging A5-V11 and GL-iNet mini routers which come in handy when working with devices without wifi and no ethernet cable in reach. but that's another story.

anon98444528 · May 15, 2020, 11:40am

I have two AP/VLANs per band and 0 vdev's...

I don't (yet) know why that's different. Since you have it configured this way, I knew I was in "over my head."

My speculation was that the 2.4 network was somehow overloaded (too much traffic trying to go through it) and "stock" firmware was better able to handle that condition. Hence my sugestion to unplug the AP from you router.

The more experienced forum users generally start troubleshooting wifi issues by asking users to remove wifi clients. That is much simpler to do than anything I suggested and if I had gone down that route you would have found the cause sooner - so my bad.

Anyway, thank you for sharing your experience.

cyablo · May 15, 2020, 12:02pm

I think that's because there are additional, unmanaged network interfaces for every vlan, bridged with the corresponding wifi to separate them from each other.

I started testing the R7800 separated from my productive network and with only one client, but put it into active operation yesterday to get some results at its final location and under load. So no need to apologize

The 2.4 GHz clients are mostly esp8266 power sockets and some IoT devices that are all part of my home automation. So there's not that much traffic on it. But it's really annoying if they don't work because the wifi is going nuts. Also, I need 2.4 GHz in some corners 5 GHz can't reach (solid brick walls).

ACwifidude · May 16, 2020, 1:50pm

Glad your issue was fixed. Interference and bandwidth competention can ruin wifi. No need to feel like an idiot. Bouncing ideas is the whole point of the forum. I’d mark this thread as solved.