From: David Lang <david@lang.hm>
To: Dave Taht <dave.taht@gmail.com>
Cc: make-wifi-fast@lists.bufferbloat.net,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] graphing airtime fairness in wifi
Date: Mon, 18 Apr 2016 17:01:09 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1604181656550.13992@nftneq.ynat.uz> (raw)
In-Reply-To: <CAA93jw6xnh2kr0UsHd218DAuy6Go1UBN6G44vZEvqN86Ay8Z7Q@mail.gmail.com>
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?
> 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?
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
next prev parent reply other threads:[~2016-04-19 0:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-18 22:35 Dave Taht
2016-04-18 22:48 ` David Lang
2016-04-18 23:02 ` Bob McMahon
2016-04-18 23:36 ` Dave Taht
2016-04-18 23:11 ` David Lang
2016-04-18 23:50 ` Dave Taht
2016-04-19 0:01 ` David Lang [this message]
2016-04-19 0:07 ` Dave Taht
2016-04-19 0:32 ` David Lang
2016-04-18 23:02 ` Isaac Konikoff
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/make-wifi-fast.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.1604181656550.13992@nftneq.ynat.uz \
--to=david@lang.hm \
--cc=bloat@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=make-wifi-fast@lists.bufferbloat.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