From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F00CD3B47C for ; Mon, 18 Apr 2016 19:14:07 -0400 (EDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id u3INE5ev031674; Mon, 18 Apr 2016 16:14:05 -0700 Date: Mon, 18 Apr 2016 16:14:05 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: davecb@spamcop.net cc: bloat@lists.bufferbloat.net In-Reply-To: <571567D6.3030209@rogers.com> Message-ID: References: <571567D6.3030209@rogers.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="===============5234858575860742371==" 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: Mon, 18 Apr 2016 23:14:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============5234858575860742371== Content-Type: TEXT/Plain; format=flowed; charset=US-ASCII 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. 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 > > > --===============5234858575860742371== Content-Type: TEXT/PLAIN; CHARSET=utf-8 Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: INLINE X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQmxvYXQgbWFp bGluZyBsaXN0CkJsb2F0QGxpc3RzLmJ1ZmZlcmJsb2F0Lm5ldApodHRwczovL2xpc3RzLmJ1ZmZl cmJsb2F0Lm5ldC9saXN0aW5mby9ibG9hdAo= --===============5234858575860742371==--