Lets make wifi fast again!
 help / color / mirror / Atom feed
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

  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