On Thu, May 28, 2020, 9:00 AM <make-wifi-fast-request@lists.bufferbloat.net> wrote:

Send Make-wifi-fast mailing list submissions to
make-wifi-fast@lists.bufferbloat.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.bufferbloat.net/listinfo/make-wifi-fast
or, via email, send a message with subject or body 'help' to
make-wifi-fast-request@lists.bufferbloat.net

You can reach the person managing the list at
make-wifi-fast-owner@lists.bufferbloat.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Make-wifi-fast digest..."
Today's Topics:

1. Re: REPOSTED: SmallNetBuilder Article: Does OFDMA really
work? Part 2 (Bob McMahon)
2. Re: REPOSTED: SmallNetBuilder Article: Does OFDMA really
work? Part 2 (Tim Higgins)
3. R7800 & openwrt and smallnetbuilder (Dave Taht)

---------- Forwarded message ----------
From: Bob McMahon <bob.mcmahon@broadcom.com>
To: Tim Higgins <tim@smallnetbuilder.com>
Cc: Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>
Bcc:
Date: Wed, 27 May 2020 10:16:23 -0700
Subject: Re: [Make-wifi-fast] REPOSTED: SmallNetBuilder Article: Does OFDMA really work? Part 2

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 <tim@smallnetbuilder.com> 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

---------- Forwarded message ----------
From: Tim Higgins <tim@smallnetbuilder.com>
To: Bob McMahon <bob.mcmahon@broadcom.com>
Cc: Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>
Bcc:
Date: Thu, 28 May 2020 10:22:04 -0400
Subject: Re: [Make-wifi-fast] REPOSTED: SmallNetBuilder Article: Does OFDMA really work? Part 2

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 <tim@smallnetbuilder.com> 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

---------- Forwarded message ----------
From: Dave Taht <dave.taht@gmail.com>
To: Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>
Cc:
Bcc:
Date: Thu, 28 May 2020 08:28:05 -0700
Subject: [Make-wifi-fast] R7800 & openwrt and smallnetbuilder
I see that the R7800 is tim's goto router. I have one in a box... somewhere...

A benchmark between the stock R7800 firmware and openwrt 19.03 on it
would be nice to have. So far as I know
most of the offloads are in 19.03. However, the work ongoing on the
ath10k is pretty relevant, so A to B to C
would be a good shower of progress.

I figure tim is burned out totally on benchmarking wifi routers and is
off restoring his karma by planting a garden or hopefully something
relaxing like that(?), but I did manage to get most of my lab
reassembled over the past few weeks.

--
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave@taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729

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