From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 44C8C3B2E8 for ; Tue, 19 Apr 2016 17:48:32 -0400 (EDT) Received: by mail-vk0-x22b.google.com with SMTP id n67so32424920vkf.3 for ; Tue, 19 Apr 2016 14:48: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; bh=u4wC3iUcuvx0fjGi3E+9nX2WFs+ZsTsZ0d8fPQ1k+kc=; b=H5y7/ACEksvz/DDGEjTNrWG0mfzvoQ40OtbssYB741gW1c12t4UzTlANeE0ki6LEWK ceahcdb+WAwsgR3NtRqWm2pHNewn1UtpA5jVA/Og1KeSsGgchznDU9cZvGXzuJ0F/AGC Z7NAfmZh7fAnKv3zqOS40+i+WiHHaFWFGS4V7MeccaSHb7Y1zLMp6JbDaleVGzcIY3LZ ywYITZvTavx2b4b1D26Mi1Wm0aQvIqHKyq9v0c4Ajo9UB/3jR8YAGGjPb0j8lrZgJCwZ VWSHTRiSD44OX0dxprVtVAVexiO5FfF9uIiggCGIi3gzK7MebwvdGAHHtISx5dv25I/r 5gPg== 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; bh=u4wC3iUcuvx0fjGi3E+9nX2WFs+ZsTsZ0d8fPQ1k+kc=; b=UwMqPtLBcOBtvjM7ojjyy7AJ6DkAsBOzM6GJhSCrAEURjeStcLLr4P8sfv9+eYtNWz AvLTuy60WrMyKDrTpfeFRA0mWCfRB7tCxF8qILMAY9kjlwgFDfBCe0wC7r3AShbWtpHf t6GgCVYZ8MTjYhbvxpuVs5SxmqdTCcNtaWhPDi2iYBRROfEKi1uGgJsv+cxRBNyB/2Ub Sk8+TNXPJ1ANVNqmlNce4SNjGWdq18Z7v4A/Ue75URPgIg8gMbITgn0+hni9/TWEpoz8 kEF+B2PV/9VW8zlqOydwRyAuqPFz6OyvNLB1i2UPwEohBYEYjzEu41h3trKdpjx4lRVR /Baw== X-Gm-Message-State: AOPr4FWcFpxjme38Qk4rzf5tMye7pKeYM6yP9JMkELo18UNW9Yxz4Md7Mi15BjFOWcYxVcR9wiA2nn3JK4WOCg== MIME-Version: 1.0 X-Received: by 10.159.37.104 with SMTP id 95mr2899218uaz.85.1461102511663; Tue, 19 Apr 2016 14:48:31 -0700 (PDT) Received: by 10.103.47.142 with HTTP; Tue, 19 Apr 2016 14:48:31 -0700 (PDT) In-Reply-To: <57158CFD.1070004@rogers.com> References: <571567D6.3030209@rogers.com> <57158CFD.1070004@rogers.com> Date: Tue, 19 Apr 2016 14:48:31 -0700 Message-ID: From: Aaron Wood To: davecb@spamcop.net Cc: bloat Content-Type: multipart/alternative; boundary=94eb2c123022302fdd0530dd7022 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 21:48:32 -0000 --94eb2c123022302fdd0530dd7022 Content-Type: text/plain; charset=UTF-8 What about a strip-chart with multiple lanes for every device. Then use either a line graph or a spectrograph (color of band) style marking to show data rate used at that time. If the main goal is fairness and airtime, then the eye can visually compute that based on how evenly spread out the slices of usage are, and can identify problematic places based on color of the band (or height of the line, if using a spark-lines instead of patches of color. I've done this in the past to visualize offline devices in a mesh network, and the result of that was _very_ useful for showing how losing one node takes out the ones that needed to route through it, also useful for showing when failures were time-correlated or not. Multicast messages could then be shown as grey bands across the whole set of spectrum, and inter-packet as just whitespace (or maybe thin black lines). If you were more interested in showing sent vs. received, then you could do two stripes per station, one for tx and one for rx. For higher encoding rates, the preamble could be shown in the 1Mbps/11Mbps color, and then the rest of the payload in a different color for the MCS used. That will show efficient aggregation vs. inefficient aggregation. Hmm... I kinda want to sketch this up using matplotlib. I've used a couple pcap libraries (like scapy) with python. They're not fast, though (scapy does about 2500pps in reading/parsing pcap files on my computer). That might be better if it was told to only parse the radio-tap header and ignore the rest of the packet. -Aaron On Mon, Apr 18, 2016 at 6:42 PM, David Collier-Brown wrote: > On 18/04/16 07:03 PM, 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 > > Rat's, it all went on one line. This is more like what I meant > > > - over time, plotting the time taken for against the load > in s is what capacity planners expect to see: "_/" > > > --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-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 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) > > 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. > > > 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 > > > > -- > David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the restdavecb@spamcop.net | -- Mark Twain > > > > -- > David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the restdavecb@spamcop.net | -- Mark Twain > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > > --94eb2c123022302fdd0530dd7022 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What about a strip-chart with multiple lanes for every dev= ice.=C2=A0 Then use either a line graph or a spectrograph (color of band) s= tyle marking to show data rate used at that time.=C2=A0 If the main goal is= fairness and airtime, then the eye can visually compute that based on how = evenly spread out the slices of usage are, and can identify problematic pla= ces based on color of the band (or height of the line, if using a spark-lin= es instead of patches of color.

I've done this in th= e past to visualize offline devices in a mesh network, and the result of th= at was _very_ useful for showing how losing one node takes out the ones tha= t needed to route through it, also useful for showing when failures were ti= me-correlated or not.

Multicast messages could the= n be shown as grey bands across the whole set of spectrum, and inter-packet= as just whitespace (or maybe thin black lines).

I= f you were more interested in showing sent vs. received, then you could do = two stripes per station, one for tx and one for rx.

For higher encoding rates, the preamble could be shown in the 1Mbps/11Mbp= s color, and then the rest of the payload in a different color for the MCS = used.=C2=A0 That will show efficient aggregation vs. inefficient aggregatio= n.

Hmm...=C2=A0 I kinda want to sketch this up usi= ng matplotlib.=C2=A0 I've used a couple pcap libraries (like scapy) wit= h python.=C2=A0 They're not fast, though (scapy does about 2500pps in r= eading/parsing pcap files on my computer).=C2=A0 That might be better if it= was told to only parse the radio-tap header and ignore the rest of the pac= ket.

-Aaron
=
On Mon, Apr 18, 2016 at 6:42 PM, David Colli= er-Brown <davec-b@rogers.com> wrote:
=20 =20 =20
On 18/04/16 07:03 PM, David Collier-Brown wrote:
=20
I haven't internalized this yet, but my instantaneous reaction is:
  • =C2=A0a radar screen is something people have been educated t= o understand, so that's cool, and
 Rat's, it all went on one line. This is more like what I meant
  • over time, plotting the time taken for <something> against the load in <something>s is what capacity planners expect to see: "_/"

--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=C2=A0 (I borrowed this graph
from=C2=A0 http://www.webde= signerdepot.com/2013/11/easily-create-stunning-animated-charts-with-chart-j= s/
)

Another way to do it would be to have the pie represent all the
stations on the network, and to have the "sweep hand" j= ump 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 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)

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.


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. <= br>
David Lang

_______________________________________________
Bloat mailing list
Bl= oat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat 


--=20
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net<=
/a>           |                      -- Mark Twain

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
https://lists.bufferbloat.net/listinfo/bloat


--94eb2c123022302fdd0530dd7022--