[Make-wifi-fast] graphing airtime fairness in wifi

[Dave Taht]

On Mon, Apr 18, 2016 at 3:48 PM, David Lang <david at lang.hm> wrote:
> On Mon, 18 Apr 2016, Dave Taht wrote:
>
>> I have been sitting here looking at wifi air packet captures off and
>> on for years now, trying to come up with a representation, over time,
>> of what the actual airtime usage (and one day, fairness) would look
>> like. Believe me, looking at the captures is no fun, and (for example)
>> wireshark tends to misinterpret unreceived retries at different rates
>> inside a txop as tcp retries (which, while educational, makes it hard
>> to see actual retries)...
>>
>> Finally today, I found a conceptual model that "fits" - and it's kind
>> of my hope that something already out there does this from packet
>> captures. (?) Certainly there are lots of great pie chart tools out
>> there...
>>
>> Basically you start with a pie chart representing a fixed amount of
>> time - say, 128ms. Then for each device transmitting you assign a
>> slice of the pie for the amount of airtime used. Then, you can show
>> the amount of data transmitted in that piece of the pie by increasing
>> the volume plotted for that slice of the pie. And you sweep around
>> continually (like a radar scanning or a timepiece's pointer) to show
>> progress over time, and you show multicast and other traffic as eating
>> the whole pie for however long it lasts.
>>
>> conceptually it looks a bit like this:
>>
>> http://blog.cerowrt.org/images/fairness.png  (I borrowed this graph
>> from
>> http://www.webdesignerdepot.com/2013/11/easily-create-stunning-animated-charts-with-chart-js/
>> )
>>
>> Another way to do it would be to have the pie represent all the
>> stations on the network, and to have the "sweep hand" jump between
>> them...
>
>
> does it really matter how much data is passed during the timeslice as
> opposed to just how much airtime is used?

Heh. Merely getting a representation of airtime plotted this way would
be a start! It is only a couple variables in the wireshark capture to
pull out, I think....

However, in following along michal's work on fq_codel for wifi, he is
not (quite) implementing an airtime fair scheduler as yet, just
applying codel (desparately needed) with fq that is sort of FCFS (not
that I have got a machine working with ath10k yet, sigh....)

I think the earlier work he did on using rate control to get a better
depth estimate is going to turn out way better than the dql approach
he tried last week. http://blog.cerowrt.org/post/dql_on_wifi_2/ - but
that said, you can't always get at rate control or aggregation
information, and getting per sta fairness is going to be more work
(and more variables to collect - maybe).

> (and there will be a large chunk
> of airtime unused for various reasons, much of which you will not be able to
> attribute to any one station, and if you do get full transmit data from each
> station, you can end up with >100% airtime use attempted)

The "black" lines on the pie chart would represent the interframe gap,
you could use a color for "other things" like mgmt frames or
interference (if you have the data), go "grey" or transparent for
unused txops.

I really wanted to be able to show the "pulse" that multicast
powersave induces every ~250ms (could also use that to change the
chart to show what stations are active), and pulses like upnp and
other big pieces of multicast traffic can induce, also, by making the
whole pie chart flash for the actual duration it took, while the sweep
hand went 'round.

Similarly, mu-mimo "soundings" - although they are very short, could
be shown, and I dunno how to show multiple stations going at once in
that mode.

(the spec suggests soundings be taken every 10ms (and take up to
500usec!!!), which is nuts. First you need per-station airtime
scheduling and queuing, then, IF you have MU-mimo capable stations
with data waiting for them, sound... and even then the only major
cases where I think this feature is going to help all that much is in
very, very dense environments, which have other problems)

>
> I would be looking at a stacked area graph to show changes over time (a
> particular source will come and go over time)
>
> I would either do two graphs, one showing data successfully transmitted, the
> other showing airtime used (keeping colors/order matching between the two
> graphs), or if you have few enough stations, one graph with good lines
> between the stations and have the color represent the % of theoretical peak
> data transmission to show the relative efficiency of the different stations.

Noted.

>
>
> While the radar sweep updating of a pie graph is a neat graphic, it doesn't
> really let you see what's happening over time.

Disagree. At least on a testbench I'm pretty sure a "good" pattern
could be recognisable against other traffic.

In the real world, monitoring a wifi network this way (per channel
available) would be a nice dashboard.

> David Lang
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org