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
>