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 D4C6A3B494; Mon, 18 Apr 2016 20:01:12 -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 u3J0190u031901; Mon, 18 Apr 2016 17:01:09 -0700 Date: Mon, 18 Apr 2016 17:01:09 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Dave Taht cc: make-wifi-fast@lists.bufferbloat.net, bloat In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Tue, 19 Apr 2016 00:01:13 -0000 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