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 <[email protected]> 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 <[email protected]> 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
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel



--
Dave Täht

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



_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Reply via email to