<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font face="Times New Roman, Times, serif">Hi Isaac,<br>
<br>
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.<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I've been checking regularly with consumer router makers to have
them provide details on what they actually support for OFDMA.<br>
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.<br>
The NETGEAR RAX15 is one of the few that does. <br>
<br>
I also ask what the minimum # of STAs are required to trigger
OFDMA operation. For ASUS, it's generally two; for NETGEAR 4.<br>
So that's why I'm testing with 4 OFDMA-capable STAs.<br>
</font><br>
<div class="moz-cite-prefix">On 4/29/2020 7:55 PM, Isaac Konikoff
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+wRhHFRqVJTnFi0za-R80CzcknNUivtTazkx3Nh4c=Per96GA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hi Tim,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Nice use of flent! Looking forward to your write-up.</div>
<div>Isaac</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Apr 29, 2020 at 2:40
PM Tim Higgins <<a href="mailto:tim@smallnetbuilder.com"
moz-do-not-send="true">tim@smallnetbuilder.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> <font size="-1" face="Times New Roman, Times, serif">Hi
all,<br>
</font><br>
<font size="-1" face="Times New Roman, Times, serif"><font
size="-1" face="Times New Roman, Times, serif">I finally
have my testbed working the way I want and am starting
to run tests to see if OFDMA does anything useful.<br>
<br>
This will all be covered in detail in an upcoming
SmallNetBuilder article. But I wanted to sanity check
something with this esteemed group.<br>
<br>
The tests are basically the flent rtt_fair_var up and
down tests ported to the octoScope platform I use for
WiFi testing.<br>
The initial work was done on flent, with a lot of
hand-holding from Toke. (Thank you, Toke!)<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
The NETGEAR R7800 is a 4x4 AC Qualcomm-based. I'm using
this as a baseline product.<br>
<br>
The NETGEAR RAX15 is 2x2 AX Broadcom-based. You can see
what I mean when I say OFDMA doesn't help.<br>
<br>
Does this much difference between up and downlink
latency pass the sniff test?<br>
</font></font>
<div><br>
<div><font size="-1" face="Times New Roman, Times, serif">===<br>
Tim</font></div>
</div>
</div>
_______________________________________________<br>
Make-wifi-fast mailing list<br>
<a href="mailto:Make-wifi-fast@lists.bufferbloat.net"
target="_blank" moz-do-not-send="true">Make-wifi-fast@lists.bufferbloat.net</a><br>
<a
href="https://lists.bufferbloat.net/listinfo/make-wifi-fast"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a></blockquote>
</div>
</blockquote>
<br>
</body>
</html>