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

[Bob McMahon]

> 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 at smallnetbuilder.com> wrote:

>
> On 4/2/2020 6:20 AM, Toke Høiland-Jørgensen wrote:
>
> Tim Higgins <tim at smallnetbuilder.com> <tim at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20200402/10117ac0/attachment.html>