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

[Dave Taht]

On Mon, Apr 18, 2016 at 5:01 PM, David Lang <david at lang.hm> wrote:
> On Mon, 18 Apr 2016, Dave Taht wrote:
>
>>> (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.
>
>
> well, in the 'river' chart, such pulses are going to stand out as well
> (assuming you are displaying things to a suitable resolution.
>
> Trying to have them show up in a pie chart seems hard. Are you really going
> to update the entire pie chart 4 times/sec? how is anyone going to see
> what's what when things are changing that fast?

8 times/sec, and a human can deal with that. However, slowing the
playback down by some factor like 10x would be useful. We had ways of
doing that in early versions of the web implementation of the flent
interpreter...

That work died a few years ago, but had some nice features on scaling
in and out on detail. Old repo here.

https://github.com/bipulkkuri/netperf-wrapper

>> 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.
>
>
> what information do we need to test this?

AirCaps, mostly. You could try to get there from timestamps alone but
I doubt it would be all that useful.

> We've got the reports from /sys for the scale APs, is this sufficient? or do
> you really need something reporting >once/sec?
>
> David Lang



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