Re: [PATCH] mac80211: Report correct wireless statistics

[Dan Williams <dcbw@redhat.com>]

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

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.

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

Dan