From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A683B3B29E for ; Thu, 28 May 2020 14:00:11 -0400 (EDT) Received: by mail-ed1-x530.google.com with SMTP id g9so793077edr.8 for ; Thu, 28 May 2020 11:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8Gvpsg1F0IWjeKA5aIbVkYQEW9QEUFuX+/wPRsZDhNE=; b=J572rfr8bBskwa8jboImG5FYb1whhW0sSJwZyzaa+oY1/0mjmwU/pKPKVFJBItIOym C9qoUnTM5D7y/pg7svMe3OE03wLyK08AlU4/ZwNC7lv7qGCtR1TwD1nh7StNuA6o5bYV EeUA4qjh7DB4HFT9oKE3PqYh696xk3FbTXeUk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8Gvpsg1F0IWjeKA5aIbVkYQEW9QEUFuX+/wPRsZDhNE=; b=nIPuikxJI+GlQhHer5+M9dkj7p2WmC97B/oi8UADoSvZWQj+OhTVCgNoelCrwew2/P TFpZDGqmd9/uq2ETVKz52l8bq9RCq+W38MaPzWxwnfZ46LMoXSZ/+Hq7NwSXD2nsvhmi rErqOuhrONo9TlT4fjvz88r6+m2e94UjJ3hKDCH2BiZ4l0hZH/FNA555ngRrse7k+CvI 5aUD0z9VHpAPs9SwT+doRzmSRwMzqpgPJd62V59I9uvPGQrK30+xJjL93iPNFYUshSEq WefMiSxEGdFB7G77XN0nndr92p74jRGN+ZIe6tXkC0G6BtXCFThzNdRkpJ/6AbbQfpZJ qDNg== X-Gm-Message-State: AOAM533EsKhPyjK+qGrEX7Dq53HUpERLcHhKp2s85BYBAs+tR9Ys2Cr3 B4SZwOjAnf93HSwLqNvbIEfrw+8Sh7vud7Qggk+oA1CPTvc= X-Google-Smtp-Source: ABdhPJw2AAY+YA46vPtECxrkpUeawCXbHZz5IVwQhzXCmScW2CaT1+yG79lxJ2r+pa13U8JgE5Ei4XKuOpWdSgNGbA0= X-Received: by 2002:a50:e44d:: with SMTP id e13mr4229296edm.373.1590688810519; Thu, 28 May 2020 11:00:10 -0700 (PDT) MIME-Version: 1.0 References: <4337569f-8df2-426f-013f-d9748f7695c1@smallnetbuilder.com> <79267524-8f69-cca5-f0de-99f30b630f5a@smallnetbuilder.com> In-Reply-To: <79267524-8f69-cca5-f0de-99f30b630f5a@smallnetbuilder.com> From: Bob McMahon Date: Thu, 28 May 2020 10:59:59 -0700 Message-ID: Subject: Re: [Make-wifi-fast] REPOSTED: SmallNetBuilder Article: Does OFDMA really work? Part 2 To: Tim Higgins Cc: Make-Wifi-fast Content-Type: multipart/alternative; boundary="000000000000802a3105a6b9191d" X-List-Received-Date: Thu, 28 May 2020 18:00:11 -0000 --000000000000802a3105a6b9191d Content-Type: text/plain; charset="UTF-8" Iperf 2.0.14 supports write to read trip times for both TCP and UDP https://youtu.be/LOGpXiAk_cc Bob On Thu, May 28, 2020 at 7:22 AM Tim Higgins wrote: > Hi Bob, > > Thanks for the suggestions. The iper2 suggests are for UDP, correct? > > As I said in the article, I'm done hunting this snark for now. Maybe > others will take up the challenge. > =========== > Tim > On 5/27/2020 1:16 PM, Bob McMahon wrote: > > I would make a small packet run too. For iperf2 use -l 40 and -b 20000pps > and vary the pps number. I would hope that OFDMA would increase this. > > Also, don't forget about jitter - the derivative of latency. Some > protocols care more about jitter than they do latency. > > I'd look into measuring the actual latency and jitter of the traffic vs > using a ping as a proxy. This will be supported in iperf 2.0.14 using the > write (server) side clock and --write-ack. Better though is to synchronize > the clocks and use one way trip times. While I like to synchronize the > realtime clocks to the GPS atomic clock as the reference, using PTP and > synchronizing to a common reference of any PC oscillator may be good > enough. PTP stats will give you errors and corrections and per the > corrections one can get an idea of the error. > > Thanks for posting. I really don't think OFDMA is going to affect such > large latencies in a noticeable manner. I think it will be the ultra low > latencies or near zero queuing that will matter. For data center switches > this is driven mostly by high frequency traders. For WiFi it's going to be > newer games with VR/AR. Those latencies are going to need to be very low > compared to today's use cases. > > my $0.02, > > Bob > > On Wed, May 27, 2020 at 7:37 AM Tim Higgins > wrote: > >> Tests have been redone and article is back up. >> =========================== >> Hi All, >> >> This article uses the benchmark test described in Part 1 to test 6 Wi-Fi >> consumer routers. Results are not impressive. >> >> https://www.smallnetbuilder.com/wireless/wireless-features/33223-does-ofdma-really-work-part-2 >> >> =========== >> Tim >> _______________________________________________ >> Make-wifi-fast mailing list >> Make-wifi-fast@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/make-wifi-fast > > > --000000000000802a3105a6b9191d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Iperf 2.0.14 supports write to read trip times for both TC= P and UDP

https://youtu.be/= LOGpXiAk_cc

Bob

On Thu, May 28, 2020 at 7:22 AM Tim Higgins <<= a href=3D"mailto:tim@smallnetbuilder.com">tim@smallnetbuilder.com> w= rote:
=20 =20 =20
Hi Bob,

Thanks for the suggestions. The iper2 suggests are for UDP, correct?

As I said in the article, I'm done hunting this snark for now. Maybe others will take up the challenge.
=20
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Tim
On 5/27/2020 1:16 PM, Bob McMahon wrote:
=20
I would make a small packet run too. For iperf2 use -l 40 and -b 20000pps and vary the pps number. I would hope that OFDMA would increase this.=C2=A0

Also, don't forget=C2=A0about jitter - the derivative of latenc= y. Some protocols care more about jitter=C2=A0than they do latency.
I'd look into measuring the actual=C2=A0latency and jitter of t= he traffic vs using a ping as a proxy. This will be supported in iperf 2.0.14 using=C2=A0the write (server) side clock and --write-ack.=C2=A0 Better though is to synchronize the clocks and u= se one way trip times. While I like to synchronize the realtime=C2=A0clocks to the GPS atomic clock as the reference, usin= g PTP and synchronizing=C2=A0to a common reference of any PC oscillat= or may be good enough. PTP stats will give you errors and corrections and per the corrections one can get an idea of the error.

Thanks=C2=A0for posting. I really don't think OFDMA is going to affect such large latencies in=C2=A0a noticeable manner. I think it will be the ultra low latencies or near zero queuing that will matter.=C2=A0 For data center switches this is driven mostly by hig= h frequency traders. For WiFi it's going to be newer games with VR/AR. Those latencies are going to need to be very low compared to today's use cases.

my $0.02,

Bob

On Wed, May 27, 2020 at 7:37 AM Tim Higgins <tim@smallnetbuilder.com> wrote:
Te= sts have been redone and article is back up.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
Hi All,

This article uses the benchmark test described in Part 1 to test 6 Wi-Fi consumer routers. Results are not impressive.
https://www= .smallnetbuilder.com/wireless/wireless-features/33223-does-ofdma-really-wor= k-part-2

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Tim
_______________________________________________
Make-wifi-fast mailing list
Make-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinf= o/make-wifi-fast

--000000000000802a3105a6b9191d--