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

[Dave Taht]

On Mon, Apr 18, 2016 at 4:14 PM, David Lang <david at lang.hm> wrote:
> On Mon, 18 Apr 2016, David Collier-Brown wrote:
>
>> I haven't internalized this yet, but my instantaneous reaction is:
>>
>> *   a radar screen is something people have been educated to
>>   understand, so that's cool, and over time, plotting the time taken
>>   for something against the load in somethings is what capacity
>>   planners expect to see: "_/"
>
>
> I agree, but a radar screen only shows the 'now', and I'm not sure how
> interesting that really is compared to how it looks over time.

Well summing the "volume" of all the samples over each interval would
be a back-asswards way of getting your bar
graph, but what I wanted to do was be able to get a comparison of the
latency over load simultaneously, also, on stuff like the 4th graph
here: http://blog.cerowrt.org/post/fq_codel_on_ath10k/


> David Lang
>
>
>>
>> --dave
>>
>> On 18/04/16 06:48 PM, David Lang 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? (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)
>>>
>>> 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.
>>>
>>>
>>> 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.
>>>
>>> David Lang
>>>
>>> _______________________________________________
>>> Bloat mailing list
>>> Bloat at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/bloat
>>
>>
>>
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>



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