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

[Bob McMahon <bob.mcmahon@broadcom.com>]

[-- 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 --]