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

[David Lang]

On Mon, 18 Apr 2016, Dave Taht wrote:

> 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.

not if they need to see any detail. let alone the 'max rate from their protocol 
version vs rate actually used' and things like 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.

if we are trying to get this from aircaps then we have multiple categories of 
things.

1. time when nothing was sent, but it looks to us like the airtime could have 
been used.

2. time when nothing was sent that we can understand, but we see enough signal 
strength that we would not transmit

3. data we see sent, and can identify the sender, but it gets mangled

4. Data we see sent that we can understand, but that gets re-transmitted

5. Data we see sent and can understand, and is acked or at least not re-sent


note that with #2 and #3 other things (including the system being transmitted 
to) may be able to understand the signal.

What we really need is hooks into the wifi stack to spit out what it sees 
(transmitting and receiving) and then gather this info (via a different network 
or after the fact) and correlate things together.

That's really the only way we are going to be able to tell the difference 
between

microwave/cordless phone/other stations just barely too far away to unserstand 
noise

something transmitted by station A to station B that B can't understand because 
something tromped on it

something transmitted by station A to station B successfully

especially in high density environments.

David Lang