linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Larry Finger <larry.finger@lwfinger.net>
To: Dan Williams <dcbw@redhat.com>
Cc: Michael Wu <flamingice@sourmilk.net>,
	John Linville <linville@tuxdriver.com>,
	Michael Buesch <mb@bu3sch.de>,
	Bcm43xx-dev@lists.berlios.de, linux-wireless@vger.kernel.org,
	Jiri Benc <jbenc@suse.cz>
Subject: Re: [PATCH] mac80211: Report correct wireless statistics
Date: Mon, 09 Apr 2007 10:49:38 -0500	[thread overview]
Message-ID: <461A6092.20701@lwfinger.net> (raw)
In-Reply-To: <1176120428.2693.12.camel@localhost.localdomain>

Dan Williams wrote:
> On Mon, 2007-04-09 at 00:43 -0400, Michael Wu wrote:
>> Yes, I did reverse your conventions, but it makes more sense this way. (R)SSI 
>> is always valid to assign to (struct iw_quality).level and signal ((struct 
>> iw_quality).qual) is quite arbitrary and cannot be specified in specific 
>> units.
>>
>> Signal should be probably be renamed to qual to make it more clear that it is 
>> arbitrary.
> 
> In WE, qual is arbitrary within a few limits:
> 
> a) qual _must_ change on a linear scale
> b) a valid max_qual.qual must be set
> c) qual must fall within the bounds of [0, max_qual.qual] inclusive

Note that the quantity supplied by the bcm43xx firmware (called jssi in the code) varies linearly 
with the strength of the signal, whereas the quantity derived from it in bcm43xx_rssi_postprocess is 
quasi logarithmic. The statement in a) above would argue against reversal of my conventions. What 
happens in the other drivers that use mac80211?
> 
> If you report 'level' in dBm, you must set the IW_QUAL_DBM flag.
> Otherwise, 'level' _may_ be assumed to be RSSI.  If 'level' is dBm,
> max_qual.level must be 0.  If 'level' is RSSI, max_qual.level must be
> greater than 0, and level must fall within the bounds of [0,
> max_qual.level] inclusive.  Replace 'level' with 'noise' here for the
> rules for noise.
> 
> I don't particularly care if level/noise is RSSI _as long as_ you give
> the max RSSI for your part.  Different radio parts have different max
> RSSI values, and if you're writing a driver you sure better know them or
> figure some reasonable ones out by experimentation.  RSSI is entirely
> vendor defined and does _not_ conform to any rules.  Therefore we need
> the max RSSI to get usable signal strength reports from your part.
> 
> I know that 0 dBm isn't actually the upper bound, but in practice most
> people aren't going to get parts that go above that.  0 dBm should be
> considered a _limitation_ of WEXT that we obviously fix with
> cfg80211/nl80211 when we bring some sanity to signal strength reporting.

If the IW_QUAL_DBM flag is set, the "maximum" for that quantity is actually interpreted as a minimum 
and the range is interpreted as [maximum..0] using s8 arithmetic.

> Again, if you report level in RSSI, you must provide the max RSSI for
> your part in max_qual.level.

Agreed.

Larry


  parent reply	other threads:[~2007-04-09 15:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-08  5:04 [PATCH] mac80211: Report correct wireless statistics Larry Finger
2007-04-08  7:48 ` Tomas Winkler
2007-04-08 15:35 ` Michael Wu
2007-04-08 22:26   ` Larry Finger
2007-04-08 23:02     ` Michael Wu
2007-04-08 23:32       ` Larry Finger
2007-04-08 23:41         ` Michael Wu
2007-04-09  0:02           ` Larry Finger
2007-04-09  0:31             ` Michael Wu
2007-04-09  3:54               ` Larry Finger
2007-04-09  4:43                 ` Michael Wu
2007-04-09  5:06                   ` Larry Finger
2007-04-09 12:07                   ` Dan Williams
2007-04-09 12:21                     ` Dan Williams
2007-04-09 15:49                     ` Larry Finger [this message]
2007-04-09 17:16                       ` Michael Wu
2007-04-09 21:12                         ` Larry Finger
2007-04-09 23:02                           ` Michael Wu
2007-04-10  0:59                             ` Larry Finger
2007-04-13 23:18                               ` Michael Wu

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=461A6092.20701@lwfinger.net \
    --to=larry.finger@lwfinger.net \
    --cc=Bcm43xx-dev@lists.berlios.de \
    --cc=dcbw@redhat.com \
    --cc=flamingice@sourmilk.net \
    --cc=jbenc@suse.cz \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mb@bu3sch.de \
    /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).