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

[Dave Taht]

On Sun, Feb 8, 2015 at 3:48 PM, David Lang <david at 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 at 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 at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>>
>>
>



-- 
Dave Täht

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