<div dir="ltr">Also, forgot to mention, for latency don't rely on average as most don't care about that. Maybe use the upper 3 stdev, i.e. the 99.97% point. Our latency runs will repeat 20 seconds worth of packets and find that then calculate CDFs of this point in the tail across hundreds of runs under different conditions. One "slow packet" is all that it takes to screw up user experience when it comes to latency. <br><br>Bob</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 14, 2020 at 2:38 PM Bob McMahon <<a href="mailto:bob.mcmahon@broadcom.com">bob.mcmahon@broadcom.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 dir="ltr">I haven't looked closely at OFDMA but these latency numbers seem way too high for it to matter. Why is the latency so high? It suggests there may be queueing delay (bloat) unrelated to media access.<br><br>Also, one aspect is that OFDMA is replacing EDCA with AP scheduling per trigger frame. EDCA kinda sucks per listen before talk which is about 100 microseconds on average which has to be paid even when no energy detect. This limits the transmits per second performance to 10K (1/0.0001.). Also remember that WiFi aggregates so transmissions have multiple packets and long transmits will consume those 10K tx ops. One way to get around aggregation is to use voice (VO) access class which many devices won't aggregate (mileage will vary.). Then take a packets per second measurement with small packets. This would give an idea on the frame scheduling being AP based vs EDCA. <br><br>Also, measuring ping time as a proxy for latency isn't ideal. Better to measure trip times of the actual traffic. This requires clock sync to a common reference. GPS atomic clocks are available but it does take some setup work.<br><br>I haven't thought about RU optimizations and that testing so can't really comment there. <br><br>Also, I'd consider replacing the mechanical turn table with variable phase shifters and set them in the MIMO (or H-Matrix) path. I use <a href="https://www.apitech.com/globalassets/documents/products/rf-microwave-microelectronics-power-solutions/rf-components/phase-shifter-subsystem/wmod84208421.pdf" target="_blank">model 8421 from Aeroflex</a>. Others make them too.<br><br>Bob</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 14, 2020 at 9:43 AM Tim Higgins <<a href="mailto:tim@smallnetbuilder.com" target="_blank">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 folks,<br>
<br>
I decided to publish some details of the hoops I've been jumping
through to try to find benefit from OFDMA.<br>
It's proving very hard to do.<br>
<br>
<a href="https://www.smallnetbuilder.com/wireless/wireless-features/33222-does-ofdma-really-work-part-1" target="_blank">https://www.smallnetbuilder.com/wireless/wireless-features/33222-does-ofdma-really-work-part-1</a><br>
<br>
I'll publish results from real devices next. But I'm still trying
different things to get SOMETHING to show an improvement from
OFDMA.<br>
<br>
Suggestions are welcome.</font><br>
<div>
<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">Make-wifi-fast@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a></blockquote></div>
</blockquote></div>