From: Kalle Valo <kalle.valo@nokia.com>
To: "Dan Williams" <dcbw@redhat.com>
Cc: Helmut Schaa <hschaa@suse.de>, linux-wireless@vger.kernel.org
Subject: Re: [RFC] mac80211: notify the user space about low signal quality
Date: Tue, 16 Sep 2008 10:53:51 +0300 [thread overview]
Message-ID: <874p4g1q7k.fsf@nokia.com> (raw)
In-Reply-To: <1221487652.10177.23.camel@localhost.localdomain> (ext Dan Williams's message of "Mon\, 15 Sep 2008 10\:07\:31 -0400")
Dan Williams <dcbw@redhat.com> writes:
> On Mon, 2008-09-15 at 14:35 +0200, Helmut Schaa wrote:
>> This patch adds a new wext event that notifies the user space about a low
>> signal quality. The currently used indicator is as follows: If three
>> successive beacons are received with a signal quality lower then 40%
>> user space gets informed.
>>
>> Any ideas about which indicators should be used? Comments?
>
> So why does this need a new event? Can't wpa_supplicant monitor the
> signal quality (or level/noise if the driver doesn't provide "quality")
> and do what it needs to do without any changes to the kernel at all?
Because that's polling. 10 years ago polling might be acceptable, but
not anymore. We need to improve our power consumption and to do that
we have to avoid waking up CPU (and rest of the system) as much as
possible.
> That's what any userspace process already does. If you're concerned
> about polling or something, we could fix that by sending periodic
> quality events
Periodic events are as worse as polling, still the CPU is waken up
unnecessarily.
> I'm concerned about adding arbitrary "roaming thresholds" to the
> stack, since that can certainly mean different things to different
> programs. It's not necessarily a system-wide value, and adding it as
> another tweakable seems unnecessary.
I don't see a problem here. We have to have a threshold somewhere and,
in my opinion, mac80211 is the best place to have it. That way it's
easier in the future when we want to improve the roaming logic because
mac80211 has the best information available to make the decision of
bad coverage to the AP.
> We've already got IWEVQUAL, why don't we use it?
Maybe, if we can provide all the necessary information to user space.
Remember that this is not all about signal level, I'm sure we will
want to use other parameters as well.
But what's so bad of adding a new event to WE? This is clearly a new
feature in WE and I don't see why we have to start overloading old
events.
--
Kalle Valo
next prev parent reply other threads:[~2008-09-16 7:55 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-15 12:16 More thoughts about roaming Helmut Schaa
2008-09-15 12:29 ` [RFC] Implement basic background scanning Helmut Schaa
2008-09-15 14:32 ` Michael Buesch
2008-09-15 14:40 ` Helmut Schaa
2008-09-15 15:59 ` Johannes Berg
2008-09-15 16:35 ` Helmut Schaa
2008-09-16 8:43 ` Kalle Valo
2008-09-16 9:10 ` Johannes Berg
2008-09-16 9:20 ` Helmut Schaa
2008-09-16 11:06 ` Johannes Berg
2008-09-16 9:15 ` Tomas Winkler
2008-09-15 12:35 ` [RFC] mac80211: notify the user space about low signal quality Helmut Schaa
2008-09-15 14:07 ` Dan Williams
2008-09-15 14:34 ` Helmut Schaa
2008-09-15 15:28 ` Dan Williams
2008-09-15 16:45 ` Helmut Schaa
2008-09-16 1:21 ` Luis R. Rodriguez
2008-09-16 7:41 ` Helmut Schaa
2008-09-16 8:07 ` Kalle Valo
2008-09-16 8:12 ` Johannes Berg
2008-09-16 8:55 ` Kalle Valo
2008-09-23 18:21 ` John W. Linville
2008-09-16 8:00 ` Kalle Valo
2008-09-16 7:57 ` Kalle Valo
2008-09-15 15:10 ` Holger Schurig
2008-09-15 15:19 ` Dan Williams
2008-09-16 8:25 ` Kalle Valo
2008-09-16 8:50 ` Holger Schurig
2008-09-16 9:25 ` Helmut Schaa
2008-09-16 9:32 ` Helmut Schaa
2008-09-16 10:23 ` Holger Schurig
2008-09-15 15:17 ` Holger Schurig
2008-09-16 7:53 ` Kalle Valo [this message]
2008-09-15 12:41 ` [RFC] wpa_supplicant: trigger a scan if signal quality is low Helmut Schaa
2008-09-15 13:59 ` More thoughts about roaming Dan Williams
2008-09-15 14:18 ` Helmut Schaa
2008-09-15 14:45 ` Dan Williams
2008-09-16 7:09 ` Kalle Valo
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=874p4g1q7k.fsf@nokia.com \
--to=kalle.valo@nokia.com \
--cc=dcbw@redhat.com \
--cc=hschaa@suse.de \
--cc=linux-wireless@vger.kernel.org \
/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).