From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 AE8BE3B494; Mon, 18 Apr 2016 20:07:33 -0400 (EDT) Received: by mail-ob0-x231.google.com with SMTP id bg3so234503obb.1; Mon, 18 Apr 2016 17:07:33 -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=QcWstarx+ZAqEkhHx37ic+vS+UVV7X2uXrTzMHltOig=; b=g90JwsXgUg3Tr7KbmELMmDg2Bqxz44KRuDZylOun8lz1uuojjdagnX2XGAys6dM1Ht n4/la1zS0aScAA7tZpg0h6sweE+9XqOGde2jr+oVe67ngCFcQEN0OHh8/SzqcSQTe/fm vHxYYKjPYRRWkfPHVahDHBtYzt35g+D6iKBLFLHm+pYecdYcm6/k5Z/dWGncjicgw1Yg DUJ5lEnj6FhlOha8Lq3nMqEvt3EXC1e/3CLsBnHCtYB4kNTtNAV65HIXOP+kSkYXUcVo GE2c0Hvww8yfUHmkFz0j+yAsr/+HFBof7mLVo+wk+2ydtGA4HMR8QzAt7OllIEhYQClk Bdiw== 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=QcWstarx+ZAqEkhHx37ic+vS+UVV7X2uXrTzMHltOig=; b=JCVKFhlvyLNmh7dBVPj7e8YFyEvhfH91NVEg97LhjQ3DMqRLgumtKhW0yo3c3/wmZF wmNmsGq6gJ3FWym4Fv3Oe7iWKnl6kYPMrq/9TfUIYpQBT1nM4lkJ1VE8jd1uk5Ty6bNH e5JaqWuo1MFj3pikPwzvz4VVeOQMRFBpjlmk7nJy0tAjV9WN1Vzex/2KZL0AqAe0xnHu eUao3JCBDBMRtG2JEmqjXmfJPJODdUlUQlrxTVHTfnEkjfFARWtn2kWX3lz0Up/ZA5Ks PLtll76HYPvelhh55YJVidJpFXas1iVbWIUD++h+udxXNZSpWA/o0eHl1jLMgLiMyqWl nfaQ== X-Gm-Message-State: AOPr4FWOJ8mp+1RTWFMdWyOs03FFC9mMQ3vH4Fytan2a54rFI2Hle7UzHm22Ky0ib/AO2y3dIzH76HIAmpJSDA== MIME-Version: 1.0 X-Received: by 10.60.85.3 with SMTP id d3mr18481810oez.69.1461024453143; Mon, 18 Apr 2016 17:07:33 -0700 (PDT) Received: by 10.202.79.194 with HTTP; Mon, 18 Apr 2016 17:07:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Apr 2016 17:07:33 -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: Tue, 19 Apr 2016 00:07:33 -0000 On Mon, Apr 18, 2016 at 5:01 PM, David Lang wrote: > 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 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) >> >> >> 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 goi= ng > to update the entire pie chart 4 times/sec? how is anyone going to see > what's what when things are changing that fast? 8 times/sec, and a human can deal with that. However, slowing the playback down by some factor like 10x would be useful. We had ways of doing that in early versions of the web implementation of the flent interpreter... That work died a few years ago, but had some nice features on scaling in and out on detail. Old repo here. https://github.com/bipulkkuri/netperf-wrapper >> 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 t= wo >>> 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? AirCaps, mostly. You could try to get there from timestamps alone but I doubt it would be all that useful. > 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 --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org