[Cerowrt-devel] what stats do people want from conference wifi?

[Cerowrt-devel] what stats do people want from conference wifi?

[David Lang]

In the next few days I'm going to be building the openwrt images to use at the 
SCaLE conference. I will have ~50 APs deployed supporting ~3k attendees. This 
will be running on WNDR3700v2 and WNDR3800 APs. Since I am compiling the 
firmware myself, I can add in patches to gather and log stats for things that 
are not normally reported

The wireless network architecture is:

separate ESSIDs for 2.4 vs 5.
each band gets bridged to a different VLAN
the APs are configured not to forward broadcast traffic from one wireless client 
to another on the same AP (although broadcast traffic from one AP probably goes 
out others after hitting the wire now that I think about it)
I have all logs from the APs sent to a central logserver
I have use rrdtool to catpture normal bandwith/cpu/etc stats
I also have rrdtool capture how many clients are connected to each ESSID every 
minute.


What else can I gather related to the wifi?

I think it would be useful if we could gather info along the lines of

amount of airtime used

how much latency is added to packets while waiting to transmit because it's hearing something else transmit?

amount of unused airtime available

average effective bit rate

percentage of time spent doing broadcasts (things required to operate at the 
lowest bit rate)




Part of the reason that I compile my own firmware images is that I completely 
disable connection tracking in the kernel (because clients may move from one AP 
to another in the middle of a connection it's a waste of cpu and memory to 
track), and as a result of these optimizations, there is actually quite a bit of 
CPU available. The boxes almost never hit 20% cpu utilization, so there's quite 
a bit available to gather other stats.

some of the stats I gather are in messages spit out by the kernel, others from 
scrips running on the box querying things in /proc or /sys, and others from 
watching logs and summarizing them once a minute. I even have a process that 
goes threough all the connection logs for the duration of the show and graph 
how many unique MAC addresses we've seen and a breakdown into the different 
vendor prefixes. If there's a way to get the data, I can support it.

If there are fq_codel stats that people would find interesting in this 
environment, I can gather those as well (both on the APs and on the Debian based 
firewall/gateway)

David Lang

Re: [Cerowrt-devel] what stats do people want from conference wifi?

[Dave Taht]

I am very interested in per sta stats - rc_stats - captured fairly
frequently - timestamped and kept on per mac order..

cat /sys/kernel/debug/ieee80211/phy*/netdev:*/stations/*/rc_stats

you might also get a good grip on simultaneous users and on user
migration by using this.

also I have found the xmit stat to be useful.




On Sun, Feb 8, 2015 at 3:02 PM, David Lang <david@lang.hm> wrote:
> In the next few days I'm going to be building the openwrt images to use at
> the SCaLE conference. I will have ~50 APs deployed supporting ~3k attendees.
> This will be running on WNDR3700v2 and WNDR3800 APs. Since I am compiling
> the firmware myself, I can add in patches to gather and log stats for things
> that are not normally reported
>
> The wireless network architecture is:
>
> separate ESSIDs for 2.4 vs 5.
> each band gets bridged to a different VLAN
> the APs are configured not to forward broadcast traffic from one wireless
> client to another on the same AP (although broadcast traffic from one AP
> probably goes out others after hitting the wire now that I think about it)
> I have all logs from the APs sent to a central logserver
> I have use rrdtool to catpture normal bandwith/cpu/etc stats
> I also have rrdtool capture how many clients are connected to each ESSID
> every minute.
>
>
> What else can I gather related to the wifi?
>
> I think it would be useful if we could gather info along the lines of
>
> amount of airtime used
>
> how much latency is added to packets while waiting to transmit because it's
> hearing something else transmit?
>
> amount of unused airtime available
>
> average effective bit rate
>
> percentage of time spent doing broadcasts (things required to operate at the
> lowest bit rate)
>
>
>
>
> Part of the reason that I compile my own firmware images is that I
> completely disable connection tracking in the kernel (because clients may
> move from one AP to another in the middle of a connection it's a waste of
> cpu and memory to track), and as a result of these optimizations, there is
> actually quite a bit of CPU available. The boxes almost never hit 20% cpu
> utilization, so there's quite a bit available to gather other stats.
>
> some of the stats I gather are in messages spit out by the kernel, others
> from scrips running on the box querying things in /proc or /sys, and others
> from watching logs and summarizing them once a minute. I even have a process
> that goes threough all the connection logs for the duration of the show and
> graph how many unique MAC addresses we've seen and a breakdown into the
> different vendor prefixes. If there's a way to get the data, I can support
> it.
>
> If there are fq_codel stats that people would find interesting in this
> environment, I can gather those as well (both on the APs and on the Debian
> based firewall/gateway)
>
> David Lang
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

Re: [Cerowrt-devel] what stats do people want from conference wifi?

[Aaron Wood]

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

I would love to see this data, especially since insights into dense wifi
environments is rare.

It seems like this might be a fascinating time to get stats from Minstrel,
for which rates clients are connected at:

Do they connect at high rates at all?
Do they stay stable at high rates, or do they see all the noise of other
APs and drop to slower rates accordingly?

-Aaron

On Sat, Feb 7, 2015 at 6:02 PM, David Lang <david@lang.hm> wrote:

> In the next few days I'm going to be building the openwrt images to use at
> the SCaLE conference. I will have ~50 APs deployed supporting ~3k
> attendees. This will be running on WNDR3700v2 and WNDR3800 APs. Since I am
> compiling the firmware myself, I can add in patches to gather and log stats
> for things that are not normally reported
>
> The wireless network architecture is:
>
> separate ESSIDs for 2.4 vs 5.
> each band gets bridged to a different VLAN
> the APs are configured not to forward broadcast traffic from one wireless
> client to another on the same AP (although broadcast traffic from one AP
> probably goes out others after hitting the wire now that I think about it)
> I have all logs from the APs sent to a central logserver
> I have use rrdtool to catpture normal bandwith/cpu/etc stats
> I also have rrdtool capture how many clients are connected to each ESSID
> every minute.
>
>
> What else can I gather related to the wifi?
>
> I think it would be useful if we could gather info along the lines of
>
> amount of airtime used
>
> how much latency is added to packets while waiting to transmit because
> it's hearing something else transmit?
>
> amount of unused airtime available
>
> average effective bit rate
>
> percentage of time spent doing broadcasts (things required to operate at
> the lowest bit rate)
>
>
>
>
> Part of the reason that I compile my own firmware images is that I
> completely disable connection tracking in the kernel (because clients may
> move from one AP to another in the middle of a connection it's a waste of
> cpu and memory to track), and as a result of these optimizations, there is
> actually quite a bit of CPU available. The boxes almost never hit 20% cpu
> utilization, so there's quite a bit available to gather other stats.
>
> some of the stats I gather are in messages spit out by the kernel, others
> from scrips running on the box querying things in /proc or /sys, and others
> from watching logs and summarizing them once a minute. I even have a
> process that goes threough all the connection logs for the duration of the
> show and graph how many unique MAC addresses we've seen and a breakdown
> into the different vendor prefixes. If there's a way to get the data, I can
> support it.
>
> If there are fq_codel stats that people would find interesting in this
> environment, I can gather those as well (both on the APs and on the Debian
> based firewall/gateway)
>
> David Lang
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

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

Re: [Cerowrt-devel] what stats do people want from conference wifi?

[Dave Taht]

as for more detailed info, doing a few boxes doing aircaps in monitor
mode would be useful. I could contribute a spare laptop IF I get back
from nz next week (I am currently flat on my back with a crippling
attack of bronchitis and not looking forward to flying), and a few
spare TB drives. or maybe a chrome book or three could be leveraged.

On Sun, Feb 8, 2015 at 3:35 PM, Dave Taht <dave.taht@gmail.com> wrote:
> I am very interested in per sta stats - rc_stats - captured fairly
> frequently - timestamped and kept on per mac order..
>
> cat /sys/kernel/debug/ieee80211/phy*/netdev:*/stations/*/rc_stats
>
> you might also get a good grip on simultaneous users and on user
> migration by using this.
>
> also I have found the xmit stat to be useful.
>
>
>
>
> On Sun, Feb 8, 2015 at 3:02 PM, David Lang <david@lang.hm> wrote:
>> In the next few days I'm going to be building the openwrt images to use at
>> the SCaLE conference. I will have ~50 APs deployed supporting ~3k attendees.
>> This will be running on WNDR3700v2 and WNDR3800 APs. Since I am compiling
>> the firmware myself, I can add in patches to gather and log stats for things
>> that are not normally reported
>>
>> The wireless network architecture is:
>>
>> separate ESSIDs for 2.4 vs 5.
>> each band gets bridged to a different VLAN
>> the APs are configured not to forward broadcast traffic from one wireless
>> client to another on the same AP (although broadcast traffic from one AP
>> probably goes out others after hitting the wire now that I think about it)
>> I have all logs from the APs sent to a central logserver
>> I have use rrdtool to catpture normal bandwith/cpu/etc stats
>> I also have rrdtool capture how many clients are connected to each ESSID
>> every minute.
>>
>>
>> What else can I gather related to the wifi?
>>
>> I think it would be useful if we could gather info along the lines of
>>
>> amount of airtime used
>>
>> how much latency is added to packets while waiting to transmit because it's
>> hearing something else transmit?
>>
>> amount of unused airtime available
>>
>> average effective bit rate
>>
>> percentage of time spent doing broadcasts (things required to operate at the
>> lowest bit rate)
>>
>>
>>
>>
>> Part of the reason that I compile my own firmware images is that I
>> completely disable connection tracking in the kernel (because clients may
>> move from one AP to another in the middle of a connection it's a waste of
>> cpu and memory to track), and as a result of these optimizations, there is
>> actually quite a bit of CPU available. The boxes almost never hit 20% cpu
>> utilization, so there's quite a bit available to gather other stats.
>>
>> some of the stats I gather are in messages spit out by the kernel, others
>> from scrips running on the box querying things in /proc or /sys, and others
>> from watching logs and summarizing them once a minute. I even have a process
>> that goes threough all the connection logs for the duration of the show and
>> graph how many unique MAC addresses we've seen and a breakdown into the
>> different vendor prefixes. If there's a way to get the data, I can support
>> it.
>>
>> If there are fq_codel stats that people would find interesting in this
>> environment, I can gather those as well (both on the APs and on the Debian
>> based firewall/gateway)
>>
>> David Lang
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> --
> Dave Täht
>
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

Re: [Cerowrt-devel] what stats do people want from conference wifi?

[David Lang]

when you say "fairly frequently", is per minute reasonable?

David Lang

On Sun, 8 Feb 2015, Dave Taht wrote:

> I am very interested in per sta stats - rc_stats - captured fairly
> frequently - timestamped and kept on per mac order..
>
> cat /sys/kernel/debug/ieee80211/phy*/netdev:*/stations/*/rc_stats
>
> you might also get a good grip on simultaneous users and on user
> migration by using this.
>
> also I have found the xmit stat to be useful.
>
>
>
>
> On Sun, Feb 8, 2015 at 3:02 PM, David Lang <david@lang.hm> wrote:
>> In the next few days I'm going to be building the openwrt images to use at
>> the SCaLE conference. I will have ~50 APs deployed supporting ~3k attendees.
>> This will be running on WNDR3700v2 and WNDR3800 APs. Since I am compiling
>> the firmware myself, I can add in patches to gather and log stats for things
>> that are not normally reported
>>
>> The wireless network architecture is:
>>
>> separate ESSIDs for 2.4 vs 5.
>> each band gets bridged to a different VLAN
>> the APs are configured not to forward broadcast traffic from one wireless
>> client to another on the same AP (although broadcast traffic from one AP
>> probably goes out others after hitting the wire now that I think about it)
>> I have all logs from the APs sent to a central logserver
>> I have use rrdtool to catpture normal bandwith/cpu/etc stats
>> I also have rrdtool capture how many clients are connected to each ESSID
>> every minute.
>>
>>
>> What else can I gather related to the wifi?
>>
>> I think it would be useful if we could gather info along the lines of
>>
>> amount of airtime used
>>
>> how much latency is added to packets while waiting to transmit because it's
>> hearing something else transmit?
>>
>> amount of unused airtime available
>>
>> average effective bit rate
>>
>> percentage of time spent doing broadcasts (things required to operate at the
>> lowest bit rate)
>>
>>
>>
>>
>> Part of the reason that I compile my own firmware images is that I
>> completely disable connection tracking in the kernel (because clients may
>> move from one AP to another in the middle of a connection it's a waste of
>> cpu and memory to track), and as a result of these optimizations, there is
>> actually quite a bit of CPU available. The boxes almost never hit 20% cpu
>> utilization, so there's quite a bit available to gather other stats.
>>
>> some of the stats I gather are in messages spit out by the kernel, others
>> from scrips running on the box querying things in /proc or /sys, and others
>> from watching logs and summarizing them once a minute. I even have a process
>> that goes threough all the connection logs for the duration of the show and
>> graph how many unique MAC addresses we've seen and a breakdown into the
>> different vendor prefixes. If there's a way to get the data, I can support
>> it.
>>
>> If there are fq_codel stats that people would find interesting in this
>> environment, I can gather those as well (both on the APs and on the Debian
>> based firewall/gateway)
>>
>> David Lang
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
>

Re: [Cerowrt-devel] what stats do people want from conference wifi?

[David Lang]

On Sat, 7 Feb 2015, Aaron Wood wrote:

> I would love to see this data, especially since insights into dense wifi
> environments is rare.

exactly what I'm trying to provide

> It seems like this might be a fascinating time to get stats from Minstrel,
> for which rates clients are connected at:
>
> Do they connect at high rates at all?
> Do they stay stable at high rates, or do they see all the noise of other
> APs and drop to slower rates accordingly?

I'm not familar with that tool, but I'll try to gather anything. pointers 
please?

Under normal conditions I'm happy to go researching, but since we install this 
in 10 days and are live in 11 (with all prep work having to work around my day 
job), I'm going to need pretty direct pointers on eithre stats to gather, 
patches to apply, or particular software packages to include and at least strong 
hints on any required configs.

David Lang

> -Aaron
>
> On Sat, Feb 7, 2015 at 6:02 PM, David Lang <david@lang.hm> wrote:
>
>> In the next few days I'm going to be building the openwrt images to use at
>> the SCaLE conference. I will have ~50 APs deployed supporting ~3k
>> attendees. This will be running on WNDR3700v2 and WNDR3800 APs. Since I am
>> compiling the firmware myself, I can add in patches to gather and log stats
>> for things that are not normally reported
>>
>> The wireless network architecture is:
>>
>> separate ESSIDs for 2.4 vs 5.
>> each band gets bridged to a different VLAN
>> the APs are configured not to forward broadcast traffic from one wireless
>> client to another on the same AP (although broadcast traffic from one AP
>> probably goes out others after hitting the wire now that I think about it)
>> I have all logs from the APs sent to a central logserver
>> I have use rrdtool to catpture normal bandwith/cpu/etc stats
>> I also have rrdtool capture how many clients are connected to each ESSID
>> every minute.
>>
>>
>> What else can I gather related to the wifi?
>>
>> I think it would be useful if we could gather info along the lines of
>>
>> amount of airtime used
>>
>> how much latency is added to packets while waiting to transmit because
>> it's hearing something else transmit?
>>
>> amount of unused airtime available
>>
>> average effective bit rate
>>
>> percentage of time spent doing broadcasts (things required to operate at
>> the lowest bit rate)
>>
>>
>>
>>
>> Part of the reason that I compile my own firmware images is that I
>> completely disable connection tracking in the kernel (because clients may
>> move from one AP to another in the middle of a connection it's a waste of
>> cpu and memory to track), and as a result of these optimizations, there is
>> actually quite a bit of CPU available. The boxes almost never hit 20% cpu
>> utilization, so there's quite a bit available to gather other stats.
>>
>> some of the stats I gather are in messages spit out by the kernel, others
>> from scrips running on the box querying things in /proc or /sys, and others
>> from watching logs and summarizing them once a minute. I even have a
>> process that goes threough all the connection logs for the duration of the
>> show and graph how many unique MAC addresses we've seen and a breakdown
>> into the different vendor prefixes. If there's a way to get the data, I can
>> support it.
>>
>> If there are fq_codel stats that people would find interesting in this
>> environment, I can gather those as well (both on the APs and on the Debian
>> based firewall/gateway)
>>
>> David Lang
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>

Re: [Cerowrt-devel] what stats do people want from conference wifi?

[Dave Taht]

On Sun, Feb 8, 2015 at 3:48 PM, David Lang <david@lang.hm> wrote:
> when you say "fairly frequently", is per minute reasonable?

every 10 sec is easier to deal with. note the cat method I showed is
inefficient.

>
> David Lang
>
>
> On Sun, 8 Feb 2015, Dave Taht wrote:
>
>> I am very interested in per sta stats - rc_stats - captured fairly
>> frequently - timestamped and kept on per mac order..
>>
>> cat /sys/kernel/debug/ieee80211/phy*/netdev:*/stations/*/rc_stats
>>
>> you might also get a good grip on simultaneous users and on user
>> migration by using this.
>>
>> also I have found the xmit stat to be useful.
>>
>>
>>
>>
>> On Sun, Feb 8, 2015 at 3:02 PM, David Lang <david@lang.hm> wrote:
>>>
>>> In the next few days I'm going to be building the openwrt images to use
>>> at
>>> the SCaLE conference. I will have ~50 APs deployed supporting ~3k
>>> attendees.
>>> This will be running on WNDR3700v2 and WNDR3800 APs. Since I am compiling
>>> the firmware myself, I can add in patches to gather and log stats for
>>> things
>>> that are not normally reported
>>>
>>> The wireless network architecture is:
>>>
>>> separate ESSIDs for 2.4 vs 5.
>>> each band gets bridged to a different VLAN
>>> the APs are configured not to forward broadcast traffic from one wireless
>>> client to another on the same AP (although broadcast traffic from one AP
>>> probably goes out others after hitting the wire now that I think about
>>> it)
>>> I have all logs from the APs sent to a central logserver
>>> I have use rrdtool to catpture normal bandwith/cpu/etc stats
>>> I also have rrdtool capture how many clients are connected to each ESSID
>>> every minute.
>>>
>>>
>>> What else can I gather related to the wifi?
>>>
>>> I think it would be useful if we could gather info along the lines of
>>>
>>> amount of airtime used
>>>
>>> how much latency is added to packets while waiting to transmit because
>>> it's
>>> hearing something else transmit?
>>>
>>> amount of unused airtime available
>>>
>>> average effective bit rate
>>>
>>> percentage of time spent doing broadcasts (things required to operate at
>>> the
>>> lowest bit rate)
>>>
>>>
>>>
>>>
>>> Part of the reason that I compile my own firmware images is that I
>>> completely disable connection tracking in the kernel (because clients may
>>> move from one AP to another in the middle of a connection it's a waste of
>>> cpu and memory to track), and as a result of these optimizations, there
>>> is
>>> actually quite a bit of CPU available. The boxes almost never hit 20% cpu
>>> utilization, so there's quite a bit available to gather other stats.
>>>
>>> some of the stats I gather are in messages spit out by the kernel, others
>>> from scrips running on the box querying things in /proc or /sys, and
>>> others
>>> from watching logs and summarizing them once a minute. I even have a
>>> process
>>> that goes threough all the connection logs for the duration of the show
>>> and
>>> graph how many unique MAC addresses we've seen and a breakdown into the
>>> different vendor prefixes. If there's a way to get the data, I can
>>> support
>>> it.
>>>
>>> If there are fq_codel stats that people would find interesting in this
>>> environment, I can gather those as well (both on the APs and on the
>>> Debian
>>> based firewall/gateway)
>>>
>>> David Lang
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>>
>>
>



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

Re: [Cerowrt-devel] what stats do people want from conference wifi?

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4539 bytes --]

I will have a handful of 'extra' 3700 APs that I could use (and on 2.4G I could 
look into bringing up some older dir-615 2.4G only APs if needed)

storage would be the issue. I can have a couple just stream over the network, 
but very many and I'll have people panicing over the thought of it possibly 
interfering with the video.

There are some privacy concerns about capturing everything, but I think we can 
get agreement given that starting last year we switched all the wifi to 
encrypted-only (metadata is still visible, so the encryption doesn't completely 
eliminate the privacy concerns, but I'm sure we can deal with the remainder on a 
case-by-case basis, possibly with some written agreement)

I hope you recover well. I want though that about a month ago.

David Lang

On Sun, 8 Feb 2015, Dave Taht wrote:

> as for more detailed info, doing a few boxes doing aircaps in monitor
> mode would be useful. I could contribute a spare laptop IF I get back
> from nz next week (I am currently flat on my back with a crippling
> attack of bronchitis and not looking forward to flying), and a few
> spare TB drives. or maybe a chrome book or three could be leveraged.
>
> On Sun, Feb 8, 2015 at 3:35 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> I am very interested in per sta stats - rc_stats - captured fairly
>> frequently - timestamped and kept on per mac order..
>>
>> cat /sys/kernel/debug/ieee80211/phy*/netdev:*/stations/*/rc_stats
>>
>> you might also get a good grip on simultaneous users and on user
>> migration by using this.
>>
>> also I have found the xmit stat to be useful.
>>
>>
>>
>>
>> On Sun, Feb 8, 2015 at 3:02 PM, David Lang <david@lang.hm> wrote:
>>> In the next few days I'm going to be building the openwrt images to use at
>>> the SCaLE conference. I will have ~50 APs deployed supporting ~3k attendees.
>>> This will be running on WNDR3700v2 and WNDR3800 APs. Since I am compiling
>>> the firmware myself, I can add in patches to gather and log stats for things
>>> that are not normally reported
>>>
>>> The wireless network architecture is:
>>>
>>> separate ESSIDs for 2.4 vs 5.
>>> each band gets bridged to a different VLAN
>>> the APs are configured not to forward broadcast traffic from one wireless
>>> client to another on the same AP (although broadcast traffic from one AP
>>> probably goes out others after hitting the wire now that I think about it)
>>> I have all logs from the APs sent to a central logserver
>>> I have use rrdtool to catpture normal bandwith/cpu/etc stats
>>> I also have rrdtool capture how many clients are connected to each ESSID
>>> every minute.
>>>
>>>
>>> What else can I gather related to the wifi?
>>>
>>> I think it would be useful if we could gather info along the lines of
>>>
>>> amount of airtime used
>>>
>>> how much latency is added to packets while waiting to transmit because it's
>>> hearing something else transmit?
>>>
>>> amount of unused airtime available
>>>
>>> average effective bit rate
>>>
>>> percentage of time spent doing broadcasts (things required to operate at the
>>> lowest bit rate)
>>>
>>>
>>>
>>>
>>> Part of the reason that I compile my own firmware images is that I
>>> completely disable connection tracking in the kernel (because clients may
>>> move from one AP to another in the middle of a connection it's a waste of
>>> cpu and memory to track), and as a result of these optimizations, there is
>>> actually quite a bit of CPU available. The boxes almost never hit 20% cpu
>>> utilization, so there's quite a bit available to gather other stats.
>>>
>>> some of the stats I gather are in messages spit out by the kernel, others
>>> from scrips running on the box querying things in /proc or /sys, and others
>>> from watching logs and summarizing them once a minute. I even have a process
>>> that goes threough all the connection logs for the duration of the show and
>>> graph how many unique MAC addresses we've seen and a breakdown into the
>>> different vendor prefixes. If there's a way to get the data, I can support
>>> it.
>>>
>>> If there are fq_codel stats that people would find interesting in this
>>> environment, I can gather those as well (both on the APs and on the Debian
>>> based firewall/gateway)
>>>
>>> David Lang
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>> --
>> Dave Täht
>>
>> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
>
>
>
>

Re: [Cerowrt-devel] what stats do people want from conference wifi?

[David Lang]

On Sun, 8 Feb 2015, Dave Taht wrote:

> On Sun, Feb 8, 2015 at 3:48 PM, David Lang <david@lang.hm> wrote:
>> when you say "fairly frequently", is per minute reasonable?
>
> every 10 sec is easier to deal with. note the cat method I showed is
> inefficient.

I had been thinking in terms of feeding them to syslog for transport and 
timestamping (I haven't looked to see how much data is in each file)

unless these files are lengthy, gathering a couple thousand copies every 10 sec 
sounds reasonable (if they are long, but short lines, we can re-write them to 
fewer, longer lines to make it reasonable), especially if we allow this to run 
with no attempt to sync the runs precisely across APs (so that they do end up 
being pretty spread out across the time)

>> On Sun, 8 Feb 2015, Dave Taht wrote:
>>
>>> I am very interested in per sta stats - rc_stats - captured fairly
>>> frequently - timestamped and kept on per mac order..
>>>
>>> cat /sys/kernel/debug/ieee80211/phy*/netdev:*/stations/*/rc_stats
>>>
>>> you might also get a good grip on simultaneous users and on user
>>> migration by using this.

we have already been running a per-min job to get the count of connected 
simultaneous users on each ESSID and logging each connection. We haven't done 
much analysis of the data afterwords yet.

David Lang


>>> also I have found the xmit stat to be useful.
>>>
>>>
>>>
>>>
>>> On Sun, Feb 8, 2015 at 3:02 PM, David Lang <david@lang.hm> wrote:
>>>>
>>>> In the next few days I'm going to be building the openwrt images to use
>>>> at
>>>> the SCaLE conference. I will have ~50 APs deployed supporting ~3k
>>>> attendees.
>>>> This will be running on WNDR3700v2 and WNDR3800 APs. Since I am compiling
>>>> the firmware myself, I can add in patches to gather and log stats for
>>>> things
>>>> that are not normally reported
>>>>
>>>> The wireless network architecture is:
>>>>
>>>> separate ESSIDs for 2.4 vs 5.
>>>> each band gets bridged to a different VLAN
>>>> the APs are configured not to forward broadcast traffic from one wireless
>>>> client to another on the same AP (although broadcast traffic from one AP
>>>> probably goes out others after hitting the wire now that I think about
>>>> it)
>>>> I have all logs from the APs sent to a central logserver
>>>> I have use rrdtool to catpture normal bandwith/cpu/etc stats
>>>> I also have rrdtool capture how many clients are connected to each ESSID
>>>> every minute.
>>>>
>>>>
>>>> What else can I gather related to the wifi?
>>>>
>>>> I think it would be useful if we could gather info along the lines of
>>>>
>>>> amount of airtime used
>>>>
>>>> how much latency is added to packets while waiting to transmit because
>>>> it's
>>>> hearing something else transmit?
>>>>
>>>> amount of unused airtime available
>>>>
>>>> average effective bit rate
>>>>
>>>> percentage of time spent doing broadcasts (things required to operate at
>>>> the
>>>> lowest bit rate)
>>>>
>>>>
>>>>
>>>>
>>>> Part of the reason that I compile my own firmware images is that I
>>>> completely disable connection tracking in the kernel (because clients may
>>>> move from one AP to another in the middle of a connection it's a waste of
>>>> cpu and memory to track), and as a result of these optimizations, there
>>>> is
>>>> actually quite a bit of CPU available. The boxes almost never hit 20% cpu
>>>> utilization, so there's quite a bit available to gather other stats.
>>>>
>>>> some of the stats I gather are in messages spit out by the kernel, others
>>>> from scrips running on the box querying things in /proc or /sys, and
>>>> others
>>>> from watching logs and summarizing them once a minute. I even have a
>>>> process
>>>> that goes threough all the connection logs for the duration of the show
>>>> and
>>>> graph how many unique MAC addresses we've seen and a breakdown into the
>>>> different vendor prefixes. If there's a way to get the data, I can
>>>> support
>>>> it.
>>>>
>>>> If there are fq_codel stats that people would find interesting in this
>>>> environment, I can gather those as well (both on the APs and on the
>>>> Debian
>>>> based firewall/gateway)
>>>>
>>>> David Lang
>>>> _______________________________________________
>>>> Cerowrt-devel mailing list
>>>> Cerowrt-devel@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>