linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zefir Kurtisi <zefir.kurtisi@neratec.com>
To: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Cc: linux-wireless@vger.kernel.org,
	Thomas Pedersen <thomas@cozybit.com>,
	johannes@sipsolutions.net, antonio@open-mesh.com,
	marek@open-mesh.com,
	Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Subject: Re: [RFC] design discussion: Collecting information for (non-peer) stations
Date: Fri, 22 Feb 2013 11:07:46 +0100	[thread overview]
Message-ID: <51274372.9030600@neratec.com> (raw)
In-Reply-To: <20130215171938.GA4140@pandem0nium>

On 02/15/2013 06:19 PM, Simon Wunderlich wrote:
> Hello wireless folks,
> 
> Mathias Kretschmer and me would like to bring another new feature to the kernel:
> Collecting information for (non-peer) stations. [...]
> 
> Cheers,
>         Simon
> 
Hi Simon,

our areas of operations obviously highly overlap, since I did the same
consideration path only recently ;)

For the frequency planning feature we are currently working on, I need those
extended statistics you are proposing with additional filtering rules (OUI or mask
based) to classify peers.

My initial idea was to do a sliding time window aggregation of those statistics in
the kernel with almost the same interface to the userspace you are proposing.

But with your integration of the spectral feature I realized how efficient relay
based continuous data transfer is (as compared to sending samples over netlink).
Consequently I revised the initial plan and consider realizing the extended
statistics collection in userspace.

The modifications required in the kernel are minimal:
* create relay file in debugfs
* provide enable flag in debugfs
* based on this flag, extract relevant information from frames and write to relay

This way, you move complexity out of the kernel and maximize flexibility for
statistical evaluation in userspace. Also, the overhead for moving data between
kernel and userspace is minimized, since you do them in bulk.

This is all in the planning phase, so I have no proof-of-concept patches yet.
Would just like to hear what your thoughts are and whether this could be the way
to go.



Thanks for your initiative
Zefir

  parent reply	other threads:[~2013-02-22 10:07 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-15 17:19 [RFC] design discussion: Collecting information for (non-peer) stations Simon Wunderlich
2013-02-18 14:30 ` Johannes Berg
2013-02-18 14:33   ` Johannes Berg
2013-02-18 14:46     ` Antonio Quartulli
2013-02-18 15:29       ` Johannes Berg
2013-02-18 15:38         ` Antonio Quartulli
2013-02-18 15:43           ` Johannes Berg
2013-02-18 15:49             ` Antonio Quartulli
2013-02-18 15:58               ` Johannes Berg
2013-02-18 16:07                 ` Antonio Quartulli
2013-02-18 16:51                   ` Johannes Berg
2013-02-18 19:36                     ` Mathias Kretschmer
2013-02-20 17:19                     ` Simon Wunderlich
2013-02-20 19:10                       ` Thomas Pedersen
2013-02-21 17:19                         ` Simon Wunderlich
2013-02-19  9:32 ` Thomas Hühn
2013-02-20 17:49   ` Simon Wunderlich
2013-02-20 18:04   ` Mathias Kretschmer
2013-02-22 10:07 ` Zefir Kurtisi [this message]
2013-02-22 11:43   ` Simon Wunderlich
2013-02-22 12:34     ` Zefir Kurtisi
2013-02-22 16:21 ` Felix Fietkau
2013-02-22 16:36   ` Antonio Quartulli
2013-02-22 17:03     ` Felix Fietkau
2013-02-22 17:42       ` Adrian Chadd
2013-02-25 10:28         ` Simon Wunderlich
2013-03-08 14:13           ` Simon Wunderlich
2013-03-11 12:01             ` Zefir Kurtisi
2013-03-25 14:43               ` Simon Wunderlich
2013-02-22 17:42       ` Thomas Pedersen

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

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

  git send-email \
    --in-reply-to=51274372.9030600@neratec.com \
    --to=zefir.kurtisi@neratec.com \
    --cc=antonio@open-mesh.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=marek@open-mesh.com \
    --cc=mathias.kretschmer@fokus.fraunhofer.de \
    --cc=simon.wunderlich@s2003.tu-chemnitz.de \
    --cc=thomas@cozybit.com \
    /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;
as well as URLs for NNTP newsgroup(s).