[Make-wifi-fast] Must a WiFi link be fully loaded to get an accurate latency measurement?

[Make-wifi-fast] Must a WiFi link be fully loaded to get an accurate latency measurement?

[Tim Higgins]

[-- Attachment #1: Type: text/html, Size: 1030 bytes --]

Re: [Make-wifi-fast] Must a WiFi link be fully loaded to get an accurate latency measurement?

[Aaron Wood]

[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]

I think that will depend on the wifi driver (on the tx side), and whether
or not it's not sending 802.11n/ac aggregate frames immediately (and how
long it's waiting).  Some drivers will buffer up packets for some period of
time before sending them out.  So on a lightly loading transmitter, in a
quiet RF airspace, the driver might add more latency than is necessary.

One thing I've seen is that the wifi aggregates, because they are so large
(64KB), can end up creating some odd RTT sawtooth patterns as a full
aggregate will contain packets with many send times, all received at once.

Here's an excellent summary:
https://datatracker.ietf.org/meeting/101/materials/slides-101-iccrg-an-update-on-bbr-work-at-google-00

-Aaron

On Wed, Apr 1, 2020 at 10:48 AM Tim Higgins <tim@smallnetbuilder.com> wrote:

> One of the things I've been wondering about as I work on OFDMA testing is
> how heavily a WiFi link needs to be loaded.
> As far as I can tell, all (most/many) of the flent scripts basically have
> netperf TCP/IP streams running full tilt.
>
> I guess put another way, how effective are the anti-bufferbloat methods at
> reducing latency on a moderately loaded link?
>
> In terms of WiFi, do I need to run a link at 90+ airtime congestion to see
> OFDMA work it's magic? Or would the lack of available airtime hinder it
> working?
>
> ===========
> Tim
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

[-- Attachment #2: Type: text/html, Size: 2599 bytes --]

Re: [Make-wifi-fast] Must a WiFi link be fully loaded to get an accurate latency measurement?

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 2928 bytes --]

A few notes:

o) Bufferbloat is about queue depth and an input rate exceeding the service
rate such that a queue becomes a standing queue.
o) Latency is end/end and can mean different things. The base assumption by
many in the network engineering community is that all queuing is in the
network stack somewhere.  But if the application is held back it's
effectively a queue too. Things like RTT mostly affect TCP byte transfer.
The amount of blocking by the application isn't measured.
o) Aggregation and transmit "lazy" on a driver doesn't typically occur for
the Voice access class.  Many test driver latency with that AC as well as BE
o) iperf 2.0.14 has a trip time latency
<https://www.youtube.com/watch?v=LOGpXiAk_cc> which is write time (or start
of burst/frame) vs final read time.  This requires --trip-time as well as
synchronized clocks. It also produces bytes in progress from an application
end/end perspective using little's law
<https://en.wikipedia.org/wiki/Little%27s_law>.

More iperf 2.0.14 videos here
<https://www.youtube.com/channel/UCaqlH3a442xaZ9humrxRHGQ/videos>

Bob

On Wed, Apr 1, 2020 at 1:22 PM Aaron Wood <woody77@gmail.com> wrote:

> I think that will depend on the wifi driver (on the tx side), and whether
> or not it's not sending 802.11n/ac aggregate frames immediately (and how
> long it's waiting).  Some drivers will buffer up packets for some period of
> time before sending them out.  So on a lightly loading transmitter, in a
> quiet RF airspace, the driver might add more latency than is necessary.
>
> One thing I've seen is that the wifi aggregates, because they are so large
> (64KB), can end up creating some odd RTT sawtooth patterns as a full
> aggregate will contain packets with many send times, all received at once.
>
> Here's an excellent summary:
> https://datatracker.ietf.org/meeting/101/materials/slides-101-iccrg-an-update-on-bbr-work-at-google-00
>
> -Aaron
>
> On Wed, Apr 1, 2020 at 10:48 AM Tim Higgins <tim@smallnetbuilder.com>
> wrote:
>
>> One of the things I've been wondering about as I work on OFDMA testing is
>> how heavily a WiFi link needs to be loaded.
>> As far as I can tell, all (most/many) of the flent scripts basically have
>> netperf TCP/IP streams running full tilt.
>>
>> I guess put another way, how effective are the anti-bufferbloat methods
>> at reducing latency on a moderately loaded link?
>>
>> In terms of WiFi, do I need to run a link at 90+ airtime congestion to
>> see OFDMA work it's magic? Or would the lack of available airtime hinder it
>> working?
>>
>> ===========
>> Tim
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

[-- Attachment #2: Type: text/html, Size: 4527 bytes --]

Re: [Make-wifi-fast] Must a WiFi link be fully loaded to get an accurate latency measurement?

[Toke Høiland-Jørgensen]

Tim Higgins <tim@smallnetbuilder.com> writes:

> One of the things I've been wondering about as I work on OFDMA testing is how
> heavily a WiFi link needs to be loaded.
> As far as I can tell, all (most/many) of the flent scripts basically have
> netperf TCP/IP streams running full tilt.
>
> I guess put another way, how effective are the anti-bufferbloat methods at
> reducing latency on a moderately loaded link?

Well, the anti-bufferbloat mitigations aim at managing packet queues.
But if the link is not loaded to capacity, packets will generally be
sent out as soon as they arrive, so there won't *be* any queue to
manage. Which means that as far as queueing is concerned, it doesn't
really matter what you do. There are other factors that can impact the
latency of an idle link, of course, but we haven't really touched those
much when working on the bloat stuff..

> In terms of WiFi, do I need to run a link at 90+ airtime congestion to
> see OFDMA work it's magic? Or would the lack of available airtime
> hinder it working?

Now this is a good question. I would expect that OFDMA to only kick in
if there is actually data queued for multiple stations. I mean,
otherwise it doesn't really gain you much? There is probably also a
tradeoff in how long you hold back packets while waiting for more data
to show up; wait too long and you're just wasting airtime, but if you
don't wait long enough you get no benefit. How the firmware scheduler
manages that is of course vital; but I guess that's what you're trying
to find out? :)

-Toke

Re: [Make-wifi-fast] Must a WiFi link be fully loaded to get an accurate latency measurement?

[Tim Higgins]

[-- Attachment #1: Type: text/html, Size: 2574 bytes --]

Re: [Make-wifi-fast] Must a WiFi link be fully loaded to get an accurate latency measurement?

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 3605 bytes --]

> There is probably also a tradeoff in how long you hold back packets while
waiting for more data to show up;

Also recall that a transmit has to adhere EDCA and NAV.  If energy detect
or virtual carrier are active the device "backs off" and arbitrates again.
Then there is the encoding and number of spatial streams which influence
propagation delay.

So packet queues aren't typically the bottleneck in uncongested scenarios
and aren't the forcing function for end/end latency.  It's typically
related to the RF conditions which includes energy by peers, same BSS or
otherwise. Then there is OS related stuff with respect to writes and reads
that can add latency per thread scheduling.  That's another reason why it
helps to measure end/end latency which includes application level writes
and reads.

The following components of latency might be helpful:

Propagation delay
Amount of time required for a message to travel from the sender to
receiver, which is a function of distance over speed with which the signal
propagates.

Transmission delay
Amount of time required to push all the packet’s bits into the link, which
is a function of the packet’s length and data rate of the link.

Processing delay
Amount of time required to process the packet header, check for bit-level
errors, and determine the packet’s destination.

Queuing delay
Amount of time the packet is waiting in the queue until it can be processed.

Bob


On Thu, Apr 2, 2020 at 7:52 AM Tim Higgins <tim@smallnetbuilder.com> wrote:

>
> On 4/2/2020 6:20 AM, Toke Høiland-Jørgensen wrote:
>
> Tim Higgins <tim@smallnetbuilder.com> <tim@smallnetbuilder.com> writes:
>
>
> One of the things I've been wondering about as I work on OFDMA testing is how
> heavily a WiFi link needs to be loaded.
> As far as I can tell, all (most/many) of the flent scripts basically have
> netperf TCP/IP streams running full tilt.
>
> I guess put another way, how effective are the anti-bufferbloat methods at
> reducing latency on a moderately loaded link?
>
> Well, the anti-bufferbloat mitigations aim at managing packet queues.
> But if the link is not loaded to capacity, packets will generally be
> sent out as soon as they arrive, so there won't *be* any queue to
> manage. Which means that as far as queueing is concerned, it doesn't
> really matter what you do. There are other factors that can impact the
> latency of an idle link, of course, but we haven't really touched those
> much when working on the bloat stuff..
>
>
> In terms of WiFi, do I need to run a link at 90+ airtime congestion to
> see OFDMA work it's magic? Or would the lack of available airtime
> hinder it working?
>
> Now this is a good question. I would expect that OFDMA to only kick in
> if there is actually data queued for multiple stations. I mean,
> otherwise it doesn't really gain you much? There is probably also a
> tradeoff in how long you hold back packets while waiting for more data
> to show up; wait too long and you're just wasting airtime, but if you
> don't wait long enough you get no benefit. How the firmware scheduler
> manages that is of course vital; but I guess that's what you're trying
> to find out? :)
>
> -Toke
>
>
> Thanks everyone for the replies. OFDMA will be adding yet another layer of
> complexity to the current brew.
> I'll post back after I do some experiments.
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

[-- Attachment #2: Type: text/html, Size: 4563 bytes --]