From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 A3A4F3B2B4; Mon, 18 Apr 2016 19:36:32 -0400 (EDT) Received: by mail-oi0-x229.google.com with SMTP id p188so205671889oih.2; Mon, 18 Apr 2016 16:36:32 -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=M68sXSLDtUUkpFkqeN2UCS6oxERWavlhtdbIPrOaJ1U=; b=mlfxOOm2oNfH2OiJremYrbJrwCJJB3X1JARavtuHhieV3/sYcGGUWpcecj8vQ87Hb0 hC237Z2+azjl8eBOs6l0i8AyECqgmNhWJ5Hp1EOF5wVAX4/4Wcyyr7cOlVwX8cOu+tFK fYNIZSud3Gf8VNKu0xgNnv/gMBBaKB0zKsWhYKC3rF5iaxQLZDN9QgmCPO6HesgCG1B6 HZhqC0wnaKMaHRbL7Iu/QCy+mcbSxvVx+vyvFLf3K86Rl2HfIOPyKD2frJg6OB1Rmmcv NlUghkg6blc0yKupynhgZV0Qfsqq4gFLimD23R3mwfpDXiH2BAVFqhc8J4oTcfMKRqdL Mqeg== 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=M68sXSLDtUUkpFkqeN2UCS6oxERWavlhtdbIPrOaJ1U=; b=AtKPeOPNJONirNQwBxBzRWzC5QMgCxsbklmDXsKddV9Yv/1Td1ZBXbr2O6Zv7a5zIH dnhJUiKXfMcyYo7zkajp0xGS6OLy4Mtf4gPLTuFJ2t8/wNbK8/pHooAJ3Hb5BosSjufI mY7bzZq6itP4+TNGUgaX7zeqIU7Sbrvh5wSES8IG39+zfDDBRlVxJMfgAqURL39bzSPq z74pfltscn+9hgPDk6zJGdQUnyNXWGwbwA8JUimnMjKvVLgVu7jtgyr9OuGQtbkIZ+OW Nzy1F5IveTe7zMCGTJ3dfeXLTFoCdEeUyXh1C+kkKk755k/qn9rDNpD1zzKf4ysaVsFW 3+ag== X-Gm-Message-State: AOPr4FXc+lVv9iqyGRms3CiRkNPnOYfA+JxjtYN0bsv3QYpXIns1ePvvXO4ngTfqzO96UOUg1weK1XtIOjdp4g== MIME-Version: 1.0 X-Received: by 10.157.4.174 with SMTP id 43mr3222779otm.127.1461022592024; Mon, 18 Apr 2016 16:36:32 -0700 (PDT) Received: by 10.202.79.194 with HTTP; Mon, 18 Apr 2016 16:36:31 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Apr 2016 16:36:31 -0700 Message-ID: From: Dave Taht To: Bob McMahon Cc: David Lang , 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:36:32 -0000 On Mon, Apr 18, 2016 at 4:02 PM, Bob McMahon wro= te: > 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 r= ate > (theoretical) and the numerator is the actual information transferred to > that device, all normalized on some unit of time (1 second?) It's simil= ar > to efficiency but gives a multiplier indicating how well fairness algorit= hms > are working. clever, and closer to a static plot that would be useful. maybe we could get closer to a jains index this way. ... Going back to the pie idea... An extension might be to scale the radius of that slice to the theoretical achievable for that station, another circle band within the circle as to what it's current rate is, and a third band for how much data we'd actually queued up to be sent. (or generate separate plots for each outlying band at the same time) > > 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 chu= nk >> of airtime unused for various reasons, much of which you will not be abl= e 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 th= e >> two graphs), or if you have few enough stations, one graph with good lin= es >> between the stations and have the color represent the % of theoretical p= eak >> data transmission to show the relative efficiency of the different stati= ons. >> >> >> 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 > > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org