Re: signal/link quality wrong?

[Sven <sr12 duke edu>]

hi, here are some suggestions and food for thought (see below for a
"patch" proposal). i appreciate any comments and feedback.

for the FAQ, a better (more detailed and informative) version of the
whitepaper i referred to earlier is actually this:
http://www.connect802.com/download/techpubs/2004/you_believe_D100201.pdf

as far as i can tell, there _are_ some (admittedly vague) guidelines as
to what the "Link Quality" as displayed in iwconfig should be: have a
look at wireless.h and iwlib.c in and  Wireless Tools or just man
iwconfig.  what various wireless drivers are reporting is a different
issue, but at least one could make an effort to (try to) comply with the
standards set in WExt (IMHO they need to be clarified a bit, though). 

what i have to say is mainly based on the current guidelines in WExt and
man iwconfig, and it is restricted to quality stuff. ie, man iwconfig
says:
       Link quality
              Overall  quality of the link. May be based on the level of
con-
              tention or interference, the bit or frame error rate, how
good
              the  received  signal is, some timing synchronisation, or
other
              hardware metric.  This  is  an  aggregate  value,  and
depends
              totally on the driver and hardware.

       Signal level
              Received signal strength (RSSI - how strong the received
signal
              is). May be arbitrary units or dBm, iwconfig uses  driver
meta
              information to interpret the raw value given
by /proc/net/wire-
              less and display the proper unit or maximum value (using 8
bit
              arithmetic).  In  Ad-Hoc  mode,  this  may be undefined
and you
              should use iwspy.

       Noise level
              Background noise level (when no packet is transmitted).
Similar
              comments as for Signal level.


FAQ 4.3 states that madwifi currently reports as the link quality RSSI /
noise floor. but RSSI is not measured in dBm, and thus the
interpretation of "20/96" as "An RSSI of 20dBm relative to a noise floor
of 96dBm" is technically incorrect. if i understand Sam (RSSI MAX is 60
or 63) and the whitepaper (Atheros recipe: Subtract 95 from RSSI to
derive dBm) correctly, an RSSI of 20 corresponds to 20 - 95 = -75dBm and
MAX RSSI is 63 (or 60) - 95 = -32dBm (-35dBm). IMHO a more useful (and
currently implementable) specification of "Link Quality" would be
"20/60", i.e. RSSI/RSSI_MAX (or % values, ie scaled to 100, but i prefer
RSSI/RSSI_MAX), but not dBm values.

what the driver really should be reporting, according to my
understanding of WExt (and my own opinion), is the "quality of the
link," which probably should be the "signal quality." the "signal
quality" is very different from the "signal strength" and from SNR
(signal-noise-ratio). while either can in some sense be used to give a
"Link Quality," signal quality is probably the closest to what is meant
by "Link Quality." 

signal quality is hard to determine, you need to take into account not
only the noise level, but also the amount of corruption in the
environment between the access point and the client (see above paper for
an excellent discussion of this issue). i understand that getting the
"signal quality" is difficult and probably currently not really
measurable with madwifi (one would have to have a better measure of the
noise, errs/corrupted/discarded packages transmitted, data rates...). 

next best to signal quality is signal strength, which is RSSI / MAX
RSSI. given that we _do have_ a relative value, IMHO the driver should
report the RSSI / MAX RSSI value instead of a dBm value as qual. i am
told the ipw2200 driver does augment this value with things like, ie
receive packet errors, link speed, etc. to get a more realistic signal
quality. figuring out an "improved" way of getting eg the qual or the
level would be a future challenge.

in the above example, for quality the driver should be reporting
absolute values:
iq->qual = 20  (=RSSI) and range->max_qual.qual = 60 (= MAX RSSI). as
WExt prefers dBm values (and not RSSI) for level and noise (see below
for WExt specs), what should be reported by the driver (as in
net/ieee80211_wireless.c) is 

iq->qual = rssi; /* or some calibrated RSSI value */
if (iq->qual > 63) /* this should be the MAX RSSI ... so it might be 60
for some cards */
	iq->qual = 63;
iq->noise = -95; /* noise floor in dBm, should be + real noise (needs to
be determined) */
iq->level = rssi - 95; /* -95 because that converts rssi to dBm. does
noise belong here? */

max values should also be set: 
range->max_qual.qual  = 63;  /* relative, MAX RSSI ... 60 for some cards
*/
range->max_qual.level = -32; /* in dBm, MAX RSSI - 95,  = -35 for some
*/
range->max_qual.noise = -95; /* noise floor */

i know this is very crude, but IMHO this would make madwifi get closer
to complying with WExt standards.

Sven 

FYI:
/* Quality of link & SNR stuff */
/* Quality range (link, level, noise)
* If the quality is absolute, it will be in the range [0 ; max_qual],
* if the quality is dBm, it will be in the range [max_qual ; 0].
* Don't forget that we use 8 bit arithmetics... */
struct iw_quality max_qual; /* Quality of the link */
/* This should contain the average/typical values of the quality
* indicator. This should be the threshold between a "good" and
* a "bad" link (example : monitor going from green to orange).
* Currently, user space apps like quality monitors don't have any
* way to calibrate the measurement. With this, they can split
* the range between 0 and max_qual in different quality level
* (using a geometric subdivision centered on the average).
* I expect that people doing the user space apps will feedback
* us on which value we need to put in each driver... */
struct iw_quality avg_qual; /* Quality of the link */
and iwlib.c
  /* People are very often confused by the 8 bit arithmetic happening
   * here.
   * All the values here are encoded in a 8 bit integer. 8 bit integers
   * are either unsigned [0 ; 255], signed [-128 ; +127] or
   * negative [-255 ; 0].
   * Further, on 8 bits, 0x100 == 256 == 0.
   *
   * Relative/percent values are always encoded unsigned, between 0 and
255.
   * Absolute/dBm values are always encoded negative, between -255 and
0.
   *
   * How do we separate relative from absolute values ? We use the
   * range to do that. The range allow to specify the real min/max
   * of the value. As the range struct only specify one bound of the
   * value, we assume that the other bound is 0 (zero).
   * For relative values, range is [0 ; range->max].
   * For absolute values, range is [range->max ; 0].
   *
   * Let's take two example :
   * 1) value is 75%. qual->value = 75 ; range->max_qual.value = 100
[ * 2) value is -54dBm. noise floor of the radio is -104dBm.
   *    qual->value = -54 = 202 ; range->max_qual.value = -104 = 152 ]
this is a bug, it should read (Dan Williams, Jean Tourrilhes)
* 2) level is -54dBm. noise floor of the radio is -104dBm.
*    qual->level = -54 = 202 ; range->max_qual.noise = -104 = 152

from the paper cited:
Conversion For Atheros: Unlike the other vendors described, Atheros uses
a formula to derive dBm. 
RSSI_Max = 60 (or 63)
Subtract 95 from RSSI to derive dBm 

On Thu, 2005-02-03 at 18:32 +0000, Matt Foster wrote: 
> Quoting Michael Renzmann (madwifi nospam otaku42 de):
> > (CC-list modified)
> > 
> > >there is a great whitepaper on this issue:
> > >www.wildpackets.com/elements/whitepapers/Converting_Signal_Strength.pdf 
> > 
> > This probably would be a nice addition for FAQ entry 4.3.
> 
> OK, I'll add a link.
> 
> Cheers.
> 
> Matt
>