[Help]: optimize AP mode performance on mt7921au adapters

[DurvalMenezes]

Checklist

• I acknowledge that support is provided on a best-effort basis.
• I acknowledge that the authors and contributors to this repository cannot be held responsible for the results of my use of any information contained in or linked from this repository.

uname

Linux REDACTED 6.10.6+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.10.6-1~bpo12+1 (2024-08-26) x86_64 GNU/Linux

lsusb

Bus 001 Device 077: ID 0e8d:7961 MediaTek Inc. Wireless_Device

rfkill

8: phy6: Wireless LAN Soft blocked: no Hard blocked: no

dkms

zfs/2.2.6, 6.10.6+bpo-amd64, x86_64: installed

iw

phy#6
        Interface wlan1
                ifindex 12
                wdev 0x600000001
                addr e8:4e:06:ac:f4:1f
                type managed
                txpower 3.00 dBm
                multicast TXQ:
                        qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes        tx-packets
                        0       0       115     0       0       0       0       20416           121

What happened?

As discussed in another issue, from this comment on: #520 (comment)

[morrownr]

Hi @DurvalMenezes

If I recall correctly, you are in AP mode showing around 500 Mbps performance and you want to bump it up to 600-650 if possible. Right?

[DurvalMenezes]

Hi @DurvalMenezes

If I recall correctly, you are in AP mode showing around 500 Mbps performance and you want to bump it up to 600-650 if possible. Right?

Your recall is perfect, that's exactly it 👍

[morrownr]

@DurvalMenezes

Hey, I have been busy on another project using AP mode but that is stabilizing so tell me, what are the details of your current status so that I can come up with some ideas to go faster.

[DurvalMenezes]

Thanks for the followup! 👍

I'm running my EDUP AX3000M mt7921-based adapter in AP mode with the attached hostapd.conf on a very capable and mostly idle Geekom A7 SFFPC, and I'm getting significantly less performance than the ~580MBps you reported, as told by running iperf3 -s on it and then the following on my also very capable and mostly idle HP Zbook 17 w/ Intel 8265 NGW wifi, directly connected to the AP:

$ ./iperf3 -c X.X.X.X
Connecting to host X.X.X.X, port 5201
[  5] local X.X.X.X port 45804 connected to X.X.X.X port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  40.2 MBytes   338 Mbits/sec    1   1.18 MBytes       
[  5]   1.00-2.00   sec  56.2 MBytes   472 Mbits/sec    0   1.53 MBytes       
[  5]   2.00-3.00   sec  57.5 MBytes   482 Mbits/sec    0   1.69 MBytes       
[  5]   3.00-4.00   sec  56.2 MBytes   472 Mbits/sec    0   1.69 MBytes       
[  5]   4.00-5.00   sec  55.0 MBytes   461 Mbits/sec    0   1.69 MBytes       
[  5]   5.00-6.00   sec  57.5 MBytes   482 Mbits/sec    0   1.88 MBytes       
[  5]   6.00-7.00   sec  55.0 MBytes   461 Mbits/sec    0   1.88 MBytes       
[  5]   7.00-8.00   sec  56.2 MBytes   472 Mbits/sec    0   1.97 MBytes       
[  5]   8.00-9.00   sec  56.2 MBytes   472 Mbits/sec    0   1.97 MBytes       
[  5]   9.00-10.00  sec  58.8 MBytes   493 Mbits/sec    0   1.97 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   549 MBytes   461 Mbits/sec    1             sender
[  5]   0.00-10.01  sec   546 MBytes   458 Mbits/sec                  receiver
iperf Done.

That connection is 802.11AC and not AX because that's what the client adapter is capable of, but even so it should be more than enough to reach the same speeds you're seeing:

# iwlist wlp3s0 bitrate
wlp3s0    unknown bit-rate information.
          Current Bit Rate:866.7 Mb/s

And to corroborate that it's really the AP that has a performance problem, I ran the same thing on my Android phone, with the WiFi adapter built into the Qualcomm Snapdragon 778G (SM7325) SoC:

$ iperf3 -c 172.26.2.1
Connecting to host 172.26.2.1, port 5201
[  5] local 172.26.2.221 port 37996 connected to 172.26.2.1 port 5201       
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  55.8 MBytes   466 Mbits/sec    0   1.93 MBytes                                                                                
[  5]   1.00-2.00   sec  59.0 MBytes   495 Mbits/sec    0   1.93 MBytes                                                                                 
[  5]   2.00-3.00   sec  56.5 MBytes   475 Mbits/sec    1   1.93 MBytes     
[  5]   3.00-4.00   sec  62.6 MBytes   525 Mbits/sec    0   1.93 MBytes     
[  5]   4.00-5.00   sec  55.2 MBytes   463 Mbits/sec    0   1.93 MBytes     
[  5]   5.00-6.00   sec  59.2 MBytes   498 Mbits/sec    0   1.93 MBytes     
[  5]   6.00-7.01   sec  66.6 MBytes   555 Mbits/sec    0   1.93 MBytes     
[  5]   7.01-8.00   sec  57.1 MBytes   482 Mbits/sec    0   1.93 MBytes                                                                                 
[  5]   8.00-9.00   sec  58.3 MBytes   489 Mbits/sec    0   1.93 MBytes                                                                                 
[  5]   9.00-10.00  sec  55.0 MBytes   460 Mbits/sec    0   1.93 MBytes     
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   585 MBytes   491 Mbits/sec    1             sender
[  5]   0.00-10.01  sec   585 MBytes   490 Mbits/sec                  receiver
iperf Done.

And on Android's Wifi "Network details" screen, I can see both Transmit and Receive link speed showing as 1200 Mbps, confirming it's 802.11AX.

Moreover, I'm pretty sure the issue has nothing to do with RF interference or propagation: the AP and the clients are on top of the same table, less than 1m distant from each other and with no obstructions in between, and running a Wifi Scanner shows that there's nothing else using channels 149/155 nor any other channel/frequency in the same range (and besides shows a signal strength of -30dBm).

So, what can I do to try and get closer to the ~580Mbps speeds you're getting?

TIA!
etc_hostapd-WiFi6.conf.txt

[morrownr]

G'day @DurvalMenezes

Let's see what we can do.

Here is some homework for you. The article has some good to know information. The idea is not for you to turn down tx power as the article title suggest but rather the article contains a lot of good information regarding the topic at hand:

https://metis.fi/en/2017/10/txpower/

Why did this come to mind?

the AP and the clients are on top of the same table, less than 1m distant from each other

When I saw that, the first thing I thought is that such a close placement could be hurting your speed due to distortion. Maybe, maybe not but it is something for you to look at. I'm showing better speed through 2 walls.

I had been working on and testing a driver on a different adapter and have now returned to the Edup 1672 like yours but I need some time to reconfigure the system that I do AP mode testing with.

[DurvalMenezes]

Thanks for the link to the article. I'm a licensed ham and I'm familiar with the concept of "distortion" (although we usually call it 'saturation', and it happens at the receiver's end due to too much signal, instead of at the transmitter as the article seems to indicate -- and at least at the much lower frequencies we hams use, it only happens with extremely high levels of signal, and/or with low-quality circuits in the receiver).

Anyway, I've just tested for this by moving the client progressively away from the AP, noting the strength of the signal, and then re-running iperf3 -c; here are my results:

Signal Strenght (dBm)	iperf3 -c results (sender/receiver)	Placement of client re: AP
-30	491/490	on the same table (less than 1m away, no obstructions)
-40	453/452	about 3m away, some furniture in the way
-45	349/348	about 5m away, one wood wall
-48	314/314	about 5m away, one glass window
-60	159/159	about 5m away, one concrete wall

So, the speed decrements proportionally to the distance and obstacles (and density of obstacles); therefore, I don't think we are seeing a case of the signal being too strong and causing distortion/saturation.

What else can we do to test?

[morrownr]

at least at the much lower frequencies we hams use

I think you are correct with that statement. I used to do a job where I had numerous radios at my disposal and they were across the spectrum. The very low part of the spectrum has very useful characteristics but the behavior is different than what we see with higher frequency equipment, which is what we are talking about. With that said, given the results of your well done tests, I am not seeing a problem caused by excess tx power. With today's usb wifi adapters, we are in a situation where tx power is basically locked according to country and channel and there is not much we can do about it accept get closer or further away if there is a problem.

What else can we do to test?

The placement of the AP can make a big difference in some cases. Have you tried different locations?

The client wifi device can make a big difference. Do you have other clients to test?

In the US, the upper channels are allowed more tx power than the lower but you are already using channel 149.

This is a sharing technology so other traffic on the same channel is going to reduce the throughput you see. Do you have other APs in your area on the same channel or on channels that overlap?

I just ran iperf3 here:

$ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.178 port 43532 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  65.8 MBytes   552 Mbits/sec    0    945 KBytes       
[  5]   1.00-2.00   sec  71.2 MBytes   598 Mbits/sec    0    945 KBytes       
[  5]   2.00-3.00   sec  71.2 MBytes   598 Mbits/sec    0    945 KBytes       
[  5]   3.00-4.00   sec  72.5 MBytes   608 Mbits/sec    0    945 KBytes       
[  5]   4.00-5.00   sec  73.8 MBytes   619 Mbits/sec    0    945 KBytes       
[  5]   5.00-6.00   sec  71.2 MBytes   598 Mbits/sec    0    945 KBytes       
[  5]   6.00-7.00   sec  71.2 MBytes   598 Mbits/sec    0    945 KBytes       
[  5]   7.00-8.00   sec  73.8 MBytes   618 Mbits/sec    0    945 KBytes       
[  5]   8.00-9.00   sec  73.8 MBytes   619 Mbits/sec    0    945 KBytes       
[  5]   9.00-10.00  sec  72.5 MBytes   608 Mbits/sec    0    945 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   717 MBytes   601 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   714 MBytes   599 Mbits/sec                  receiver

With a link speed or 1200 Mbps and given that this is a half duplex technology, we can expect a max throughput of about 600 Mbps. That happens in a perfect situation and I much be pretty close to that even though it does not seem that way because my client system is about 4 meters and 2 walls away from the AP. I am seeing a signal level of -39 dBm and a link quality of 100%.

I did little clean up work on the example hostapd.conf but I think it is already tweaked as far as it can be. You might double check the settings.

The lost 100 Mbps is caused by something being different. Checking with a different client and whether you have some steady traffic on the channel are where I would start.

[morrownr]

One thing I just thought of: What computer are you using with the Edup adapter as an AP? I say this because I have come across a couple of users that were using very low capability cpu's like a RasPi 2. We looked at everything and then figured out that the lack of cpu power was limiting the speed of the AP. It was cpu bound... running at 100%. I'm using a RasPi4b quad core system that has more than enough power to max out the adapters we are using.

[DurvalMenezes]

Thank you very much for your detailed messages! I'm away from my computer now, will answer them in detail as soon as I'm back.

Just want to comment on this:

One thing I just thought of: What computer are you using with the Edup adapter as an AP?

It's the same Geekom A7 I started the testing with. It's a 7940HS 8-core/16-thread CPU, it was mostly idle during the testing, and to make sure I monitored CPU usage during the test and it was never over 5% total (system + user); in fact, minimum idle time was always at or over 95%, as indicated by vmstat.