General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: David Lang <david@lang.hm>
To: Dave Taht <dave.taht@gmail.com>
Cc: David Collier-Brown <davecb@spamcop.net>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [Make-wifi-fast] graphing airtime fairness in wifi
Date: Mon, 18 Apr 2016 17:15:57 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.02.1604181712551.13992@nftneq.ynat.uz> (raw)
In-Reply-To: <CAA93jw4tSJn70V_4biKsd1cFp20oVMSNFG_jg1EA3zoy43PWiw@mail.gmail.com>

On Mon, 18 Apr 2016, Dave Taht wrote:

> On Mon, Apr 18, 2016 at 4:14 PM, David Lang <david@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/

people are really bad at summing volumes over time, and with a pie graph, the 
volumes are odd-shaped, which people are also really bad at comparing (they can 
tell A > B, but not A = 2xB with volumes)

overlapping lines on a graph makes sense if the things being measured are fairly 
independent. In this case, you are not only wanting to show the relative airtime 
used, but also the percentage of total airtime used. That part of the display 
works far better as a stacked area graph. You can then overlay it with a single 
latency line without much trouble, but if you try to add much more it starts 
getting too cluttered.

David Lang

>
>
>> 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@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/bloat
>>>
>>>
>>>
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>
>
>
>

  reply	other threads:[~2016-04-19  0:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-18 22:35 [Bloat] " Dave Taht
2016-04-18 22:48 ` [Bloat] [Make-wifi-fast] " David Lang
2016-04-18 23:02   ` Bob McMahon
2016-04-18 23:36     ` Dave Taht
2016-04-18 23:03   ` David Collier-Brown
2016-04-18 23:14     ` David Lang
2016-04-19  0:02       ` Dave Taht
2016-04-19  0:15         ` David Lang [this message]
2016-04-19  1:42     ` David Collier-Brown
2016-04-19 21:48       ` Aaron Wood
2016-04-21 17:59         ` David Lang
2016-04-18 23:11   ` David Lang
2016-04-18 23:50   ` Dave Taht
2016-04-19  0:01     ` David Lang
2016-04-19  0:07       ` Dave Taht
2016-04-19  0:32         ` David Lang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.02.1604181712551.13992@nftneq.ynat.uz \
    --to=david@lang.hm \
    --cc=bloat@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    --cc=davecb@spamcop.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox