Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: David Lang <david@lang.hm>
Cc: "cerowrt-devel@lists.bufferbloat.net"
	<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] what stats do people want from conference wifi?
Date: Sun, 8 Feb 2015 15:57:47 +1300	[thread overview]
Message-ID: <CAA93jw4CwptRxFKbtZdJqa_MFz4fS5rE6OjQjDbVRKjoMPcMqQ@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1502071848302.2499@nftneq.ynat.uz>

On Sun, Feb 8, 2015 at 3:48 PM, David Lang <david@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@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
>>
>>
>>
>>
>>
>



-- 
Dave Täht

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

  reply	other threads:[~2015-02-08  2:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-08  2:02 David Lang
2015-02-08  2:35 ` Dave Taht
2015-02-08  2:40   ` Dave Taht
2015-02-08  3:08     ` David Lang
2015-02-08  2:48   ` David Lang
2015-02-08  2:57     ` Dave Taht [this message]
2015-02-08  3:27       ` David Lang
2015-02-08  2:36 ` Aaron Wood
2015-02-08  2:53   ` David Lang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw4CwptRxFKbtZdJqa_MFz4fS5rE6OjQjDbVRKjoMPcMqQ@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=david@lang.hm \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox