Hi Isaac,

I'm not doing captures of each test. But I do run captures of down and uplink traffic for each router before I test it.
I confirmed the RAX15 is using HE_MU QoS frames. But use varies throughout the run and not all STAs use OFDMA all the time.

Also, since I can capture only one AID at a time, I can't get a complete picture of HE_MU frames. That would require multiple sniffers for uplink OFDMA.

I generally look for HE_MU QoS frames (radiotap.he.data_1.ppdu_format == 0x2 && wlan.fc.type_subtype == 0x0028) to see if an AP is *really* supporting OFDMA. Trigger frames are one thing; real OFDMA data is another.

For the RAX15, I found all HE_MU QoS frames in the downlink capture were Best Effort Priority (0). This was with a mix of Best Effort (0), Background (1), Video(5) and Voice(6) traffic.

I've been checking regularly with consumer router makers to have them provide details on what they actually support for OFDMA.
It's still limited, but getting better. Only a handful of products support both DL and UL and even fewer support it on both bands.
The NETGEAR RAX15 is one of the few that does.

I also ask what the minimum # of STAs are required to trigger OFDMA operation. For ASUS, it's generally two; for NETGEAR 4.
So that's why I'm testing with 4 OFDMA-capable STAs.

On 4/29/2020 7:55 PM, Isaac Konikoff wrote:
Hi Tim,

I know this will probably be in your write-up, but I am curious if you are sniffing the traffic to verify that OFDMA is actually happening by pinning the aid to the monitor interface and using a wireshark display filter radiotap.he.data_1.ppdu_format==0x2 to see the HE_MU frames. From my testing it is not something that is automatically in use all the time...it is used as needed per each AP's decision algorithm. I seem to be able to cause OFDMA to happen sometimes when using small payloads with bursty traffic and periods of quiet, but it is not something that I can turn on and just say OFDMA is happening.

Also, in my flent tcp_download vs tcp_upload tests I see similar latency values that are both relatively low. I will have to run the rtt_fair_var to see how it compares.

Nice use of flent! Looking forward to your write-up.
Isaac


On Wed, Apr 29, 2020 at 2:40 PM Tim Higgins <tim@smallnetbuilder.com> wrote:
Hi all,

I finally have my testbed working the way I want and am starting to run tests to see if OFDMA does anything useful.

This will all be covered in detail in an upcoming SmallNetBuilder article. But I wanted to sanity check something with this esteemed group.

The tests are basically the flent rtt_fair_var up and down tests ported to the octoScope platform I use for WiFi testing.
The initial work was done on flent, with a lot of hand-holding from Toke. (Thank you, Toke!)

Using 4 Intel AX200 STAs on Win10. iperf3 is running traffic using TCP/IP with unthrottled bandwidth. I've taken Bjørn's idea and have each STA using a different DSCP priority level, but with TCP/IP traffic, not UDP. I'm sticking to using CS0-7 equivalents and confirmed that the iperf3 --dscp values properly translate to the intended WiFi priority levels.  Each STA has a different priority, either CS0,3,5 or 6 (best effort, excellent effort, video and voice).

Ping is used to measure latency and always runs from AP to STA. Only TCP/IP traffic direction is reversed between the down and uplink tests.

One thing that jumps out immediately is that uplink latencies are *much* lower than downlink, with either OFDMA on or off. Attached are three examples. The CDFs are average latency of the 4 STAs.

The NETGEAR R7800 is a 4x4 AC Qualcomm-based. I'm using this as a baseline product.

The NETGEAR RAX15 is 2x2 AX Broadcom-based. You can see what I mean when I say OFDMA doesn't help.

Does this much difference between up and downlink latency pass the sniff test?

===
Tim
_______________________________________________
Make-wifi-fast mailing list
Make-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wifi-fast