STA-to-STA OFDMA issue?

[sfx2000]

TLDR; There does seem to be a significant change in behavior when running simultaneous up and down traffic with UL/DL OFDMA enabled/disabled in a Broadcom-based AP that is not found with a Qualcomm-based AP.

Sounds like Broadcom has a scheduler issue with UL-OFDMA, the QC-Atheros behavior is what I would expect to see...

 

[STNVIDNOYE]

Great test, thanks! It would also be nice to understand - this happens with any client, or only with Intel.

 

[thiggins]

Sounds like Broadcom has a scheduler issue with UL-OFDMA, the QC-Atheros behavior is what I would expect to see...

Spot on @sfx2000 . Here's another plot of the ASUS GT-AX11000 with no OFDMA, DL only and DLUL. DL only has some effect, but DLUL is much worse.
Odd that MCS doesn't change this time. But it could be a reporting issue.
@STNVIDNOYE I agree that it would be nice to try other STAs, but that will have to wait for another time.

 

[tarzan2000]

The note.

Disabling OFDMA / 802.11ax MU-MIMO - gives me a drop in the test speed on the AX client (iphone 11 pro) from 600 Mbps to 200 Mbps.

 

[STNVIDNOYE]

The note.

What kind of router are you using? And can you try to disable OFDMA, but leave MU-MIMO ON?

 

[thiggins]

The note.

Disabling OFDMA / 802.11ax MU-MIMO - gives me a drop in the test speed on the AX client (iphone 11 pro) from 600 Mbps to 200 Mbps.

This would be a different issue. Both OFDMA and MU-MIMO take effect only when two or more devices that support them are active at the same time.

 

[tarzan2000]

What kind of router are you using? And can you try to disable OFDMA, but leave MU-MIMO ON?

AX86U

This would be a different issue. Both OFDMA and MU-MIMO take effect only when two or more devices that support them are active at the same time.

In my case, I can only carry out tests on 1 client AX (80Mhz) and one client AC 160 MHz (Intel 9560). So far I saw a drop in speed on the AX client and turning off the option over.

I'll run some more tests more closely.

 

[leerees]

Spot on @sfx2000 . Here's another plot of the ASUS GT-AX11000 with no OFDMA, DL only and DLUL. DL only has some effect, but DLUL is much worse.
Odd that MCS doesn't change this time. But it could be a reporting issue.
@STNVIDNOYE I agree that it would be nice to try other STAs, but that will have to wait for another time.
View attachment 36806

Can I suggest you try and test again but this time load your network with 60 AX STA's all doing different things.

Obviously there's going to be some variability but you should still see much lower latency with OFDMA DL enabled.

 

[tarzan2000]

AX (2R2T_80) <--------> AX (2R2T_160) = 50-70% drop speed with OFDMA / 802.11ax + MU-MIMO active
AX (2R2T_80) <--------> AX (2R2T_160) = 50% drop speed with OFDMA / 802.11ax DL \ UL active
AX (2R2T_80) <--------> AX (2R2T_160) = no difference in baud rate with active OFDMA / 802.11ax DL
AX (2R2T_80) <--------> AX (2R2T_160) = no difference in baud rate when OFDMA / 802.11ax is inactive
AC (2R2T_160) <--------> AX (2R2T_160) = no difference in baud rate for any option

Client's :
Iphone 11pro AX (80)
Lenovo x270 + Intel 210 6e AX (160) - Surprisingly, I didn't get an error from the Whitelist Lenovo
Intel NUCi7 + Intel 9560 AC (160)

Test's :
iperf3
Openspeed.com (local W11x64)

Router : Asus AC86U +Merlin's FW (last)

 

[STNVIDNOYE]

I was able to perform additional speed tests on the AX73 router with Intel AX200 and AX210 clients running in AX mode. This time I used two independent server-client pairs working simultaneously (LAN-> WLAN) + (LAN-> WLAN). That is, the Iperf3 servers are connected to the router with a cable. Clients are wireless.
The commands i used are of this kind. For DL (from server to client):
iperf-3.1.3-win64 \ iperf-3.1.3-win64 \ iperf3.exe -c 192.168.1.70 -R -P 8 -t 30
And for UL (from client to server):
iperf-3.1.3-win64 \ iperf-3.1.3-win64 \ iperf3.exe -c 192.168.1.70 -P 8 -t 30
Router settings:
Power high, channel 36, width 160, WPA2 / WPA3-Personal, 802.11a / n / ac / ax mixed
TWT, Smart Connect - OFF
MU-MIMO, WMM, Airtime Fairness, Zero Wait DFS - ON
A lot of numbers were received, I will try to give only the main ones.
So.
If only one LAN-> WLAN pair works at a time, then with the first server I get a DL speed of about 700-730, and with the second 810-820. In the opposite direction, these are 680 and 880. Hereinafter, I will assume that the difference of 50-100 is at the level of measurement errors.
If on one client open two Iperf windows at once and run two tests in parallel with both servers (in order to bypass the 1 GB limit on one LAN port), then at a channel speed of 2400 each client is able to get a total traffic speed of about 1100-1300 (DL and UL are roughly equal).
Now we launch both pairs at the same time and look at their mutual influence. Unfortunately, the total speed of both pairs does not reach those indicators that I see when working with only one client.
So, if both pairs work on DL, then their total speed is about 750-770.
At UL, it turns out a little more in total - about 900-1000.
In this case, the speeds between the pairs are distributed fairly symmetrically. Roughly speaking, this is 450 on one pair and 450 on the other. In total - 900.
In the case of multidirectional traffic (one pair - UL, the second - DL), no changes are observed - all the same 900-1000.
When enabling / disabling MU-MIMO, no changes are observed! The speeds are almost identical. Although in such a test at least some percentage of differences could well have been! I suspect MU-MIMO doesn't work here at all. Well, or my clients are too close to each other and to the router for MU-MIMO to work.
I have not yet revealed any effect from Airtime Fairness either, but in such a test, I suppose, it should not have a strong influence on anything.
But when I enable OFDMA, the effect is still noticeable, and it is still negative. But now it is clearly visible at what specific point it occurs.
So, we do the same thing, but with OFDMA enabled.
If both client-server pairs work on DL or both pairs work on UL, then there are no major changes. Moreover, in DL mode, the total speed even grows slightly - from 750 to 900-1000! In the opposite direction (UL) it falls slightly: from 900 to 750-800.
But once you make multidirectional traffic, that is, one pair works on DL, and the second - on UL, the traffic symmetry disappears, and the UL speed drops sharply. We get 450 DL and 135 UL. In total - about 600. I tried all combinations of client-server and each time the pair, the client of which was in UL mode, gave a speed of 130-170, no more. Of course, if I carried out the WLAN-WLAN test, then its total speed would not exceed the speed of the slowest point, that is, it would be about 130-200.
I tried to set the "Increase throughput" flag in the Intel adapter settings - no effect was observed.
But as soon as one of the clients is switched to AC mode, everything becomes quite symmetrical again, and the total speed of the two UL + DL pairs turns out to be above 900.
That's it.

 

[thiggins]

Sounds like you validated my findings on another Broadcom-based router.

 

[STNVIDNOYE]

Regarding OFDMA issue, another answer came from the TP-link support:

at the moment, negotiations are underway with the chipset manufacturer to improve this functionality.

 

[Tech9]

Advertised before properly implemented, again. We've seen this happening before.

 

[STNVIDNOYE]

I did a similar test on TP-Link AX55, where the Qualcom chip is used. There is no such glitch.

 

[STNVIDNOYE]

Hmm ... If you believe this, it looks like OFDMA is permanently disabled in the AX55 firmware. And the position of the OFDMA checkbox does not play any role. Maybe that's why the issue was not noticed on a router with a qualcomm chipset? Is there a way to check the real working of the OFDMA at home?
PS. Sorry, its not AX55 firmware, its Mercusys MR70X. But for him the support of OFDMA is also declared.
And it looks like OFDMA is not activated by default in AX23 firmware, may be - all AX series from TP-Link/Mercusys has issue (Broadcom chipset) or disabled (with Qualcomm or MTK chipset?) OFDMA...

 

[sfx2000]

If you believe this, it looks like OFDMA is permanently disabled in the AX55 firmware. And the position of the OFDMA checkbox does not play any role. Maybe that's why the issue was not noticed on a router with a qualcomm chipset? Is there a way to check the real working of the OFDMA at home?

Isn't that your 2.4GHz radio?

It's appropriate that the VHT MU don't apply for 2.4GHz...

 

[STNVIDNOYE]

It was not me who took the screenshot. But I'm talking about exactly that part of the code where the enabling of OFDMA is deactivated. look at the last line. There is an unconditional shutdown of the OFDMA. and the condition (dependence on the ofdma flag in the web interface) is commented out. Its for all firmware versions...

 

[sfx2000]

It was not me who took the screenshot. But I'm talking about exactly that part of the code where the enabling of OFDMA is deactivated. look at the last line. There is an unconditional shutdown of the OFDMA. and the condition (dependence on the ofdma flag in the web interface) is commented out. Its for all firmware versions...

You are seeing part of a shell script, and to get proper context you need the whole shebang...

Cannot tell anything with a partial screen shot...

 

[leerees]

Hmm ... If you believe this, it looks like OFDMA is permanently disabled in the AX55 firmware. And the position of the OFDMA checkbox does not play any role. Maybe that's why the issue was not noticed on a router with a qualcomm chipset? Is there a way to check the real working of the OFDMA at home?
PS. Sorry, its not AX55 firmware, its Mercusys MR70X. But for him the support of OFDMA is also declared.
And it looks like OFDMA is not activated by default in AX23 firmware, may be - all AX series from TP-Link/Mercusys has issue (Broadcom chipset) or disabled (with Qualcomm or MTK chipset?) OFDMA...

View attachment 38043

Upload is incredibly hard to measure as most if not all ISP's rarely deliver consistent upload speeds. Contention is a huge issue regardless of how your Internet is delivered. It's evident from DOCSIS to full fibre.

 

[sfx2000]

Upload is incredibly hard to measure as most if not all ISP's rarely deliver consistent upload speeds. Contention is a huge issue regardless of how your Internet is delivered. It's evident from DOCSIS to full fibre.

IIRC, OP is doing LAN to LAN, so the observations are valid.

LAN to WAN, yes, contention can always be a problem...