From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from roobidoo.pudai.com (unknown [216.14.118.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6B8803B29D for ; Fri, 15 May 2020 11:20:34 -0400 (EDT) Received: from [71.219.88.243] (port=5485 helo=[10.168.3.100]) by roobidoo.pudai.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1jZc8Y-0004vt-2I; Fri, 15 May 2020 10:20:34 -0500 Cc: tim@smallnetbuilder.com, Make-Wifi-fast To: Bob McMahon References: <56a03e99-3337-bf4a-4743-deb93abb9592@smallnetbuilder.com> From: Tim Higgins Message-ID: <6d8fc82a-cd32-31ba-023c-4dcd7822bb1d@smallnetbuilder.com> Date: Fri, 15 May 2020 11:20:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - roobidoo.pudai.com X-AntiAbuse: Original Domain - lists.bufferbloat.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smallnetbuilder.com X-Get-Message-Sender-Via: roobidoo.pudai.com: authenticated_id: tim@timhiggins.com X-Authenticated-Sender: roobidoo.pudai.com: tim@timhiggins.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Make-wifi-fast] SmallNetBuilder article: Does OFDMA Really Work? X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 15:20:34 -0000 Hi Bob= ,

Thanks for your comments and feedback. Responses below:

On 5/14/2020 5:42 PM, Bob McMahon wrote:

Also, forgot to mention, for latency don't rely on= average as most don't care about that.=C2=A0 Maybe use the upper = 3 stdev, i.e. the 99.97% point.=C2=A0 Our latency runs will repeat = 20 seconds worth of packets and find that then calculate CDFs of this point in the tail across hundreds=C2=A0of runs under differe= nt conditions. One "slow packet" is all that it takes to screw up user experience when it comes to latency.=C2=A0

Thanks= for the guidance.

On Thu, May 14, 2020 at 2:3= 8 PM Bob McMahon <bob.mcmahon@broadcom.com> wrote:

=
I haven't looked closely at OFDMA but these latency numbers seem way too high for it to matter.=C2=A0 Why= is the latency so high?=C2=A0 It suggests there may be queueing delay (bloat) unrelated to media access.

Also, one aspect is that OFDMA is replacing EDCA with AP scheduling per trigger frame.=C2=A0 EDCA kinda sucks per list= en before talk which is about 100 microseconds on average which has to be paid even when no energy detect.=C2=A0 This limits = the transmits per second performance to 10K (1/0.0001.). Also remember that WiFi aggregates so transmissions have multiple packets and long=C2=A0transmits will consume those 10K tx ops= =2E 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=C2=A0= with small packets.=C2=A0 This would give an idea on the frame scheduling being AP based vs EDCA.=C2=A0=C2=A0

Also, measuring ping time as a proxy for latency isn't ideal. Better to measure trip times of the actual traffic.=C2= =A0 This requires clock sync to a common reference. GPS atomic clocks are available but it does take some setup work.

I haven't thought about RU optimizations and that testing so can't really comment there.=C2=A0

Also, I'd consider replacing the mechanical turn table=C2=A0w= ith variable phase shifters and set them in the MIMO (or H-Matrix) path.=C2=A0 I use model 8421 from Aeroflex. Others make them too.

Thanks= again for the suggestions. I agree latency is very high when I remove the traffic bandwidth caps. I don't know why. One of the key questions I've had since starting to mess with OFDMA is whether it helps under light or heavy traffic load. All I do know is that things go to hell when you load the channel. And RRUL test methods essentially break OFDMA.

I agree using ping isn't ideal. But I'm approaching this as creating a test that a consumer audience can understand. Ping is something consumers care about and understand.=C2=A0 The octoScop= e STApals are all ntp sync'd and latency measurements using iperf have been done by them.