From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nm12-vm6.access.bullet.mail.bf1.yahoo.com (nm12-vm6.access.bullet.mail.bf1.yahoo.com [216.109.114.245]) (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 4A0D63B4A3 for ; Mon, 18 Apr 2016 21:42:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s2048; t=1461030142; bh=F7hDCDp0etCjUqjBxWeSO6aVw4pn5LJNDTQyK+F8w2U=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To:From:Subject; b=Ow5fK37BdPvnBjloPKojlk49JDnonFH9Y2LOawqc1xvEsuIH3AZPr7941yWGyUilSucNKucozEHaQCYOSPH+LFtowAKQ0EqVsNe3/2C4R3jUa0eTIcSNb0CJptC4jQWZuS10g68QUZ2iQ8fZSWklbxxPNsEGcG7XxLD8FkSNBKYeA8LBGXWbtfyu0cxJges9qQERPe5QS0ZhDhL48FKV9Q2gaDWpHMRaqCeJYWEtuDCbzvTYrbxzv6DAsaavf+c960/ESXONq4NBv5Fm3kPzRpQfz/9Z5GZomh3Qq277GjT6V4Fqdu5raqBf1mMIhGo+hYZNpQT08sjp6MO7vhmQGg== Received: from [66.196.81.157] by nm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 19 Apr 2016 01:42:22 -0000 Received: from [98.138.226.240] by tm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 19 Apr 2016 01:42:22 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.ne1.yahoo.com with NNFMP; 19 Apr 2016 01:42:22 -0000 X-Yahoo-Newman-Id: 491805.65090.bm@smtp111.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: CogLcZwVM1nCsp1Q9oYQA32.3eb0ONLX_suaRDr2hrJhKyZ Y664Ndb5RNoqBU6.tDFPVAM9Csc1Q2sW2dnAWvznVC9Ijtccw6vY2gvYwMqi QQ0xc3DHqgW99lsK.YmYMQPUCGPLtELspwW_xEEVwkddl2GwzOvFd3HlYBhF lXXFMjkANARznaWHlH34_zStuCgk_NmK3NmlSgp.U2Nsr.fsd4UKZDsA_aD2 lhckSjeXzk_9VfMqUyAA61C4SLe_KWBEZk9XebAbY5Xp7C18.iPY6MWi70JE ULS3KrPWN.SJ4yZ6AHJkPOazj3kxvhMICWHRubw25Nm.jlC3vqRTdffYifqk PuCZonLSLpbBG5oN.VVhNH9hiDygBu30RUUQdH8.vRSZyk1lOsCluOOhp5v3 PlV.cUdb_G0hq55GPfTA99KAlPRn4RnX.oHtLTS_duHTm7gRIqe3VrKSWxm1 Vt_LmL5espFytqRIOWJ.DV5E_Zd.cTqwLJ_1r4U_s34eeFz.14LhGEHfRzVS qsWG4dHSf.Sa.HoDOG.vJsu5ywl4AZFdIh5mot4LPSPflHxZvfrNYue2X5MR z4TvcSRPC99I- X-Yahoo-SMTP: sltvjZWswBCRD.ElTuB1l9j6s9wRYPpuyTNWOE5oEg-- Reply-To: davecb@spamcop.net References: <571567D6.3030209@rogers.com> To: bloat@lists.bufferbloat.net From: David Collier-Brown Message-ID: <57158CFD.1070004@rogers.com> Date: Mon, 18 Apr 2016 21:42:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <571567D6.3030209@rogers.com> Content-Type: multipart/alternative; boundary="------------000805040206000706090704" Subject: Re: [Bloat] [Make-wifi-fast] graphing airtime fairness in wifi X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 01:42:23 -0000 This is a multi-part message in MIME format. --------------000805040206000706090704 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 18/04/16 07:03 PM, 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 > Rat's, it all went on one line. This is more like what I meant > > * over time, plotting the time taken for against the > load in s is what capacity planners expect to see: "_/" > > > --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 > > > -- > David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the rest > davecb@spamcop.net | -- Mark Twain -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain --------------000805040206000706090704 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 18/04/16 07:03 PM, 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

Rat's, it all went on one line. This is more like what I meant

over time, plotting the time taken for <something> against the load in <something>s is what capacity planners expect to see: "_/"

--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
-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain

--------------000805040206000706090704--