[Make-wifi-fast] graphing airtime fairness in wifi

[Make-wifi-fast] graphing airtime fairness in wifi

[Dave Taht]

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...



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Make-wifi-fast] graphing airtime fairness in wifi

[David Lang]

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

Re: [Make-wifi-fast] graphing airtime fairness in wifi

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 3398 bytes --]

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
rate (theoretical) and the numerator is the actual information transferred
to that device, all normalized on some unit of time (1 second?)   It's
similar to efficiency but gives a multiplier indicating how well fairness
algorithms are working.

Bob

On Mon, Apr 18, 2016 at 3:48 PM, David Lang <david@lang.hm> 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
>
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>

[-- Attachment #2: Type: text/html, Size: 4546 bytes --]

Re: [Make-wifi-fast] graphing airtime fairness in wifi

[Isaac Konikoff]

Metageek's eye p.a. tool does something similar for all stations in the 
pcap.
http://www.metageek.com/products/eye-pa/

It also does the tree-pie graphs and lets you view the packets for a 
particular conversation and export filtered views back to wireshark.

The only negatives I've found is that its analyze tab only appears to 
work on ht20 channels where the center frequency and channel frequency 
are the same and it chokes on large captures...maybe I just need more 
memory. But it is useful for visualizing wtf is going on wifi-wise as 
well as what rates and when certain stations are transmitting at and 
what some protocols are doing like 11r roaming.

You can get a short trial license, but I would ask them if they would 
donate a FBO make-wifi-fast license.

Isaac

On 04/18/2016 03:35 PM, 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...
>
>
>

-- 
Isaac Konikoff
Candela Technologies
konikofi@candelatech.com
Office: 360-380-1618
Mobile: 360-389-2453

Re: [Make-wifi-fast] graphing airtime fairness in wifi

[David Lang]

On Mon, 18 Apr 2016, 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.

If you are looking for visualization that shows you what's talking to what, with 
what volume of packets of what size, take a look at.

https://it.wiki.usu.edu/OIP

David Lang

Re: [Make-wifi-fast] graphing airtime fairness in wifi

[Dave Taht]

On Mon, Apr 18, 2016 at 4:02 PM, Bob McMahon <bob.mcmahon@broadcom.com> wrote:
> 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 rate
> (theoretical) and the numerator is the actual information transferred to
> that device, all normalized on some unit of time (1 second?)   It's similar
> to efficiency but gives a multiplier indicating how well fairness algorithms
> 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 <david@lang.hm> 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
>>
>>
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Make-wifi-fast] graphing airtime fairness in wifi

[Dave Taht]

On Mon, Apr 18, 2016 at 3:48 PM, David Lang <david@lang.hm> 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 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.

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 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.

In the real world, monitoring a wifi network this way (per channel
available) would be a nice dashboard.

> David Lang
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Make-wifi-fast] graphing airtime fairness in wifi

[David Lang]

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 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)
>
> 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 going to 
update the entire pie chart 4 times/sec? how is anyone going to see what's what 
when things are changing that fast?

> 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 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?

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

Re: [Make-wifi-fast] graphing airtime fairness in wifi

[Dave Taht]

On Mon, Apr 18, 2016 at 5:01 PM, David Lang <david@lang.hm> 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 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)
>>
>>
>> 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 going
> 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 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.
>>
>>
>> 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



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Make-wifi-fast] graphing airtime fairness in wifi

[David Lang]

On Mon, 18 Apr 2016, Dave Taht wrote:

> On Mon, Apr 18, 2016 at 5:01 PM, David Lang <david@lang.hm> 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 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)
>>>
>>>
>>> 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 going
>> 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.

not if they need to see any detail. let alone the 'max rate from their protocol 
version vs rate actually used' and things like 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 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.
>>>
>>>
>>> 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.

if we are trying to get this from aircaps then we have multiple categories of 
things.

1. time when nothing was sent, but it looks to us like the airtime could have 
been used.

2. time when nothing was sent that we can understand, but we see enough signal 
strength that we would not transmit

3. data we see sent, and can identify the sender, but it gets mangled

4. Data we see sent that we can understand, but that gets re-transmitted

5. Data we see sent and can understand, and is acked or at least not re-sent


note that with #2 and #3 other things (including the system being transmitted 
to) may be able to understand the signal.

What we really need is hooks into the wifi stack to spit out what it sees 
(transmitting and receiving) and then gather this info (via a different network 
or after the fact) and correlate things together.

That's really the only way we are going to be able to tell the difference 
between

microwave/cordless phone/other stations just barely too far away to unserstand 
noise

something transmitted by station A to station B that B can't understand because 
something tromped on it

something transmitted by station A to station B successfully

especially in high density environments.

David Lang