Re: [PATCH] mac80211: Report correct wireless statistics

[Dan Williams <dcbw@redhat.com>]

On Mon, 2007-04-09 at 08:07 -0400, Dan Williams wrote:
> On Mon, 2007-04-09 at 00:43 -0400, Michael Wu wrote:
> > On Sunday 08 April 2007 23:54, Larry Finger wrote:
> > > Why would I want to do this?
> > Did it fix the output?
> > 
> > > If the community agrees on anything, it is 
> > > that the signal is given in dBm (i.e. a negative number) and that the rssi
> > > is a positive number.
> > Nope. dBm doesn't have to be negative, though it often is since most wireless 
> > hardware isn't that powerful. RSSI is simply a number that's bigger for 
> > stronger signals. It could be dBm, but it doesn't have to be. If you want a 
> > stronger definition of RSSI, look at RCPI.
> > 
> > > The firmware in the bcm43xx chips return a quantity 
> > > that looks like an rssi with a received packet, and
> > > bcm43xx_rssi_postprocess turns that into a quantity that looks like dBm.
> > > Your patch reverses those designations and mixes up the two quantities.
> > > Again I ask "Why"?
> > >
> > Because of the naming/use of the statistics in mac80211 and WE. Signal ends up 
> > getting assigned to (struct iw_quality).qual, which is actually just an 
> > arbitrary link quality indicator, not dBm. Anything you care about can be put 
> > there. (r)ssi gets assigned to (struct iw_quality).level, which is RSSI. WE 
> > allows that and noise to be specified in either arbitrary units or dBm or 
> > RCPI.
> > 
> > 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

d) max_qual.qual must be greater than 0

> 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.

RSSI doesn't conform to any rules _except_ that has a lower bound of 0
and an upper bound of the max for your part.  WE happens to provide only
a u8 for the value, so if your vendor defines RSSI as > 255 you must
somehow stuff RSSI into a u8.

14.2.3.2 RXVECTOR RSSI
    The receive signal strength indicator (RSSI) is an optional
parameter that has a value of 0 through RSSI Max.

Every vendor has a different max; Symbol's max is (at least used to be)
31.  Cisco aironet's max is 100.  Atheros' max appears to be 60.
Therefore, you must specify your max RSSI level in max_qual.level if you
use RSSI so that userspace tools can actually use your RSSI to produce
meaningful numbers.

Dan

> 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.
> 
> Again, if you report level in RSSI, you must provide the max RSSI for
> your part in max_qual.level.
> 
> Dan
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html