On Sun, Feb 8, 2015 at 3:48 PM, David Lang <[email protected]> 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 <[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
