From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 A6C273B494 for ; Mon, 18 Apr 2016 20:02:13 -0400 (EDT) Received: by mail-oi0-x230.google.com with SMTP id r78so508531oie.0 for ; Mon, 18 Apr 2016 17:02:13 -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=1xT3VjD5ywBfHeHJAsL4ubxIeFHXVo4wBk4S/34VWVk=; b=JP3QJrkvvrZeepoMDX1L2a6QWu4LAPuTPGknnXqMitO4JArT2Kex5k+kStUUm438wA CrobwusHy4PAYHfhb7OyOALbppiuCeV80nWDAztqm9ZKAMXwkCeA1cGInVueBpRils0S QYZFuEUm5xIR/USihwPgWEako6uDoPFiazdH5kmoyxzVSv3Yp0bWSio7t5czrEPX5KY/ 5j2qyBliKX9NxoAGdEb1F+3/05uONatVJNzuU6KRccXmqBhm5JOwO8pd6ps+KIHbiaZD sZMI8OSdMI8phVSLsv3yr8G486cCTkQ3Rn56yzVxF+QAwft4ibfD1/0Hmyh2RT5ims64 c70g== 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=1xT3VjD5ywBfHeHJAsL4ubxIeFHXVo4wBk4S/34VWVk=; b=dJn0nKYBaoyJo5jNTcj29sdLN4y08CCuynKP2GYEQeV6aWi9ZxwzqEq8p+RtMXqE// 1MgXs7ryg5gJ+Ob1PR7al+zXx60K8ZkKAtSca7CPavhA/dfBdxIk2uugUrFZGMMmMoJI zxNQvQvHo1e6lcgpnCXd0xWlVgc7373rxduik4nOPwJHRjKYEzhZqCK+J8zJvTt5FG9O tl+j5w4VEo4YuWJSntdyA3PfO85DSESWSYj4zclPOKQePqKLvZM4JkI0h8A/qD6Ewf8a SnSlyYfwk2UGADeT+KB0igUqmZrcxKPDNpgcf70B+PQMO/vVD/QSlxb+3C/ziNN9bWON cAQw== X-Gm-Message-State: AOPr4FVzbnn/NKrHzwu97rypD7GEdy22Moa1bucf7sS7e+4PKc2lcz97wFZMesfrD57Xi+3G9Jb0402ufENj+A== MIME-Version: 1.0 X-Received: by 10.202.178.135 with SMTP id b129mr7633098oif.139.1461024133264; Mon, 18 Apr 2016 17:02:13 -0700 (PDT) Received: by 10.202.79.194 with HTTP; Mon, 18 Apr 2016 17:02:13 -0700 (PDT) In-Reply-To: References: <571567D6.3030209@rogers.com> Date: Mon, 18 Apr 2016 17:02:13 -0700 Message-ID: From: Dave Taht To: David Lang Cc: David Collier-Brown , bloat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 00:02:13 -0000 On Mon, Apr 18, 2016 at 4:14 PM, David Lang wrote: > 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. Well summing the "volume" of all the samples over each interval would be a back-asswards way of getting your bar graph, but what I wanted to do was be able to get a comparison of the latency over load simultaneously, also, on stuff like the 4th graph here: http://blog.cerowrt.org/post/fq_codel_on_ath10k/ > 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-animate= d-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 ch= unk >>> of airtime unused for various reasons, much of which you will not be ab= le 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 t= he >>> two graphs), or if you have few enough stations, one graph with good li= nes >>> between the stations and have the color represent the % of theoretical = peak >>> data transmission to show the relative efficiency of the different stat= ions. >>> >>> >>> 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 >> >> >> > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org