From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4AB963B47C for ; Mon, 18 Apr 2016 19:02:14 -0400 (EDT) Received: by mail-wm0-x22e.google.com with SMTP id n3so2536185wmn.0 for ; Mon, 18 Apr 2016 16:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Tk2TbLDxtWxx4BisdrUdtx+WDKHcvwTwPnA4YNHCDq0=; b=GoNchdxcsa4nIaYKwvfpRnUoKg4wzsv//omz/dX2jK589Tzbyky6zZG5rmJlZbnRzo xk6E7jrGHj+CQzKLVPO8IjlbGA3J0yh5lmYtROw6fspcTKOq71GJ7qfg274kBgL1QYUU H8jkLxnp48KtaN5rZeL4wRcmrqCePY/7DH7JE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Tk2TbLDxtWxx4BisdrUdtx+WDKHcvwTwPnA4YNHCDq0=; b=dhjKtKqnMJXeCPD0FDt2Ha9ihJTGY9Y6enZFdUfiy4E9hD9NpUOr4JP7CSJ7mLkixY OgW/+sVwsg6K4j48GF0sHsXxUvq9RdeD83PCT5zmsnB4bsPjfY7CCRMnoaqupXBFaeU3 7rbSNR1KS4SJXY+fcXpXjtsp/KhKtr9gOzLmzk5HcLG65/CA55AtbMBho/31BGO7CbBu bhSATjG/cXn6iGwoA5uAqdbHHwmGId1s3mPcd3dJWlwGJBZPntzgCY0iPsUTUSb41CY4 l+2UzQVDV7ryxdAWUzquBwQ6FTBHiflbAeaE59J2sKSWbXLKfSdPjmajKOPC6j4J3Ht2 PZ9Q== X-Gm-Message-State: AOPr4FXV/ry7SaZfzw4xPNjcidt1eW4AQqvlBLOFzVPyXihBa9sYfIPl14MWbFVWwZHnNqsSip6Q7b526ZxvDL9Q MIME-Version: 1.0 X-Received: by 10.28.9.135 with SMTP id 129mr8623779wmj.31.1461020533261; Mon, 18 Apr 2016 16:02:13 -0700 (PDT) Received: by 10.194.235.232 with HTTP; Mon, 18 Apr 2016 16:02:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Apr 2016 16:02:13 -0700 Message-ID: From: Bob McMahon To: David Lang Cc: Dave Taht , make-wifi-fast@lists.bufferbloat.net, bloat Content-Type: multipart/alternative; boundary=001a11443f60e593260530ca5907 X-Mailman-Approved-At: Mon, 02 May 2016 15:49:25 -0400 Subject: Re: [Make-wifi-fast] graphing airtime fairness in wifi X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 23:02:14 -0000 --001a11443f60e593260530ca5907 Content-Type: text/plain; charset=UTF-8 Another way might be to think about it from the fairness scheduler perspective - compute a "benefit ratio" for each end device where the denominator is the information that would be transferred using a legacy rate (theoretical) and the numerator is the actual information transferred to that device, all normalized on some unit of time (1 second?) It's similar to efficiency but gives a multiplier indicating how well fairness algorithms are working. Bob On Mon, Apr 18, 2016 at 3: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 > > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast > --001a11443f60e593260530ca5907 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Another way might be to think about it from the fairness s= cheduler perspective - compute a "benefit ratio" for each end dev= ice where the denominator is the information that would be transferred usin= g a legacy rate (theoretical) and the numerator is the actual information t= ransferred to that device, all normalized on some unit of time (1 second?) = =C2=A0 It's similar to efficiency but gives a multiplier indicating how= well fairness algorithms are working.

Bob

On Mon, Apr 18, 201= 6 at 3:48 PM, David Lang <david@lang.hm> wrote:
On Mon, 18 Apr 20= 16, 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= 9;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=C2=A0 (I = borrowed this graph
from=C2=A0 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 betwee= n
them...

does it really matter how much data is passed during the timeslice as oppos= ed to just how much airtime is used? (and there will be a large chunk of ai= rtime unused for various reasons, much of which you will not be able to att= ribute to any one station, and if you do get full transmit data from each s= tation, you can end up with >100% airtime use attempted)

I would be looking at a stacked area graph to show changes over time (a par= ticular source will come and go over time)

I would either do two graphs, one showing data successfully transmitted, th= e other showing airtime used (keeping colors/order matching between the two= graphs), or if you have few enough stations, one graph with good lines bet= ween the stations and have the color represent the % of theoretical peak da= ta transmission to show the relative efficiency of the different stations.<= br>

While the radar sweep updating of a pie graph is a neat graphic, it doesn&#= 39;t really let you see what's happening over time.

David Lang


_______________________________________________
Make-wifi-fast mailing list
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast

--001a11443f60e593260530ca5907--