From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 894823B49A; Mon, 18 Apr 2016 19:50:57 -0400 (EDT) Received: by mail-oi0-x236.google.com with SMTP id p188so139176oih.2; Mon, 18 Apr 2016 16:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=ihUFxxV+183escF+nWlryqNwLD9Iwz9NokjMi8Dmhak=; b=bZGN6ozgpIW8XMMFZuxxP0Eo8wrKJ0IdiLM+0ETbFDf9/WXBpn8cgIwrLhPiwtSj6h 01J6X7o7YgX7myC9gQa94s48EzPjhba6HuUT5wdiSu/iH54dOchtX7725+WrtTtQnFO0 MXW1EygOM4rGnnti0EqVNfOHspCzRW3D5kSPzJ7gdXnqc/gYoUe/HVdZiW/m+qYfMg/K ou1g0RZuXGYfjYfGbB4QvLh6M9Q+ACaUeFyY7Ki9DtI8LfEmMZ3yfkAECXVZsQmw49HH 4fL4LBoEFTGuHZMKADD8AawS+KaQiVnmXQUyqywloCqwBDZSAGy+6j9cvJEU8jpuT909 gUgA== 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:content-transfer-encoding; bh=ihUFxxV+183escF+nWlryqNwLD9Iwz9NokjMi8Dmhak=; b=ZT9Upw0BJJ3bnu6NV2y7Z35f+W5K/a7Og/YxMSPJpjGEP4YJeUyUry3TvAU2IDf+P3 fOlC9IkZ5jnhqnTobJeB+8n4xnBWxP/FbiG1pEKydA+wtrruwAf4x9YLYO6bD0qQg47v hL1jf7C80j4Xxmw6HPTIKdG5g8Jg6Q6DkwA3f1LJkWigu44IZejvzpdZ0pREyJHFBl1N tsfR6gCRSZkqmv8kcaYpb1R/a3yboDZCI8DN4zioqRcAB8iMMPVmcHaz4RtytQIR3Bfr CGHCiMgh0rGt1w46395roUrY6c4kjlm65o67lbIJtg8BwiWi8kZ1vJxWESvTSt6ez3B5 bg5Q== X-Gm-Message-State: AOPr4FUlXGU893eKGcGAJJsDX55z2ayyER1bteylGVORN29nalaL/KKkzU8rJj2rkVU9xxAc6cfsclnRoBv/zQ== MIME-Version: 1.0 X-Received: by 10.157.4.174 with SMTP id 43mr3238552otm.127.1461023457015; Mon, 18 Apr 2016 16:50:57 -0700 (PDT) Received: by 10.202.79.194 with HTTP; Mon, 18 Apr 2016 16:50:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Apr 2016 16:50:56 -0700 Message-ID: From: Dave Taht To: David Lang Cc: make-wifi-fast@lists.bufferbloat.net, bloat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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:50:57 -0000 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? Heh. Merely getting a representation of airtime plotted this way would be a start! It is only a couple variables in the wireshark capture to pull out, I think.... However, in following along michal's work on fq_codel for wifi, he is not (quite) implementing an airtime fair scheduler as yet, just applying codel (desparately needed) with fq that is sort of FCFS (not that I have got a machine working with ath10k yet, sigh....) I think the earlier work he did on using rate control to get a better depth estimate is going to turn out way better than the dql approach he tried last week. http://blog.cerowrt.org/post/dql_on_wifi_2/ - but that said, you can't always get at rate control or aggregation information, and getting per sta fairness is going to be more work (and more variables to collect - maybe). > (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 e= ach > 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. 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 pe= ak > data transmission to show the relative efficiency of the different statio= ns. 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. In the real world, monitoring a wifi network this way (per channel available) would be a nice dashboard. > David Lang > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org