linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: Helmut Schaa <hschaa@suse.de>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC] mac80211: notify the user space about low signal quality
Date: Mon, 15 Sep 2008 11:28:49 -0400	[thread overview]
Message-ID: <1221492529.10177.76.camel@localhost.localdomain> (raw)
In-Reply-To: <200809151634.06448.hschaa@suse.de>

On Mon, 2008-09-15 at 16:34 +0200, Helmut Schaa wrote:
> Am Montag, 15. September 2008 16:07:31 schrieb Dan Williams:
> > 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?
> 
> I thought about that as well but I'm not sure if the signal quality/strength 
> is a well enough indicator.

Beacon misses should be a factor in quality, just like failed
decryptions or excessive retries.  Any of these are indications that the
"link" sucks and you might want to try finding a better AP.  Beacon
misses are just one piece of the whole quality thing.

> For example if we want to consider the number of missed beacons the current 
> IWEVQUAL event is not enough to expose this information.
> Additionally some devices can report missed beacons. Maybe even the quality 
> values reported by the drivers are not comparable at all (although they are 
> normalized to be between 0 and 100). Hence my intention was that mac80211 and 
> the driver might know better which indicators matter.

So if the values aren't comparable, we _make_ them comparable.  The
drivers can certainly tell mac80211 which things they are capable of
reporting for quality and the stack can figure them in to the final
"quality" measurement.  However, I do agree that having separate
indicators for the different factors is a good thing.  Thus something
like what Holger suggests would be better from my perspective than an
ethereal concept like a "roaming threshold".  Maybe just a poor choice
of terms?

Dan



  reply	other threads:[~2008-09-15 15:28 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 [this message]
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
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=1221492529.10177.76.camel@localhost.localdomain \
    --to=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).