From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 08F5121F340 for ; Sat, 7 Feb 2015 18:57:48 -0800 (PST) Received: by mail-oi0-f46.google.com with SMTP id a141so17778480oig.5 for ; Sat, 07 Feb 2015 18:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UzPIlXaDdz9ZwXItEGPz2nKmzjzMXZ9AHnwRoq9qwoI=; b=zZYPet/yFXn6bwywU6DQ6U8dVnHnKadCKqIf48jPcV1JWna7Akc6pc2fL3qPKixOIJ XTPITjKMTHofUNQXB36icaBDzr0J+Ij7GGxFJVdn+7R8MKor7MiRqH0KuppCfYDCqmI7 9R6YOOgS/cJgiGDinQtDuzcphqB05S2IjKHPMi8+Wp2cTdJoME+tRjaOazOHDuEuVOp7 nknH3XDktisi51j2LuUOlpdd6DsJCCxgq7GN/7aP2uwZbfZflRlKIrM2mFH20GAv3mSd 6w1kjKeIph+lzM5swZxZjQD0VpWIwEPqrmTapDVWQCItxetCO/XVhW6MjQGzoyR+WSQS pxgA== MIME-Version: 1.0 X-Received: by 10.202.62.70 with SMTP id l67mr7069061oia.59.1423364267852; Sat, 07 Feb 2015 18:57:47 -0800 (PST) Received: by 10.202.51.66 with HTTP; Sat, 7 Feb 2015 18:57:47 -0800 (PST) In-Reply-To: References: Date: Sun, 8 Feb 2015 15:57:47 +1300 Message-ID: From: Dave Taht To: David Lang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] what stats do people want from conference wifi? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 02:58:17 -0000 On Sun, Feb 8, 2015 at 3:48 PM, David Lang 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 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 compili= ng >>> 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 wirele= ss >>> client to another on the same AP (although broadcast traffic from one A= P >>> 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 ESSI= D >>> 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 a= t >>> 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 m= ay >>> 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% c= pu >>> 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, othe= rs >>> 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 >> >> >> >> >> > --=20 Dave T=C3=A4ht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks