Re: CVS-2-2 NMApplet empty bar explained

[Jean Tourrilhes <jt hpl hp com>]

On Fri, Feb 04, 2005 at 01:47:49PM -0500, Dan Williams wrote:
> On Fri, 2005-02-04 at 13:25 -0500, Sven wrote:
> > thanks for the info - i have a few more questions/suggestions:
> > 
> > if the card reports RSSI and i know MAX_RSSI, is the relative "signal
> > strength" then  RSSI / MAX_RSSI (* 100)? if one wants to use that as the
> > reported "Link Quality" but for some reason do not want to use %, what
> > should one do? converting the RSSI #'s to dBm and using that to compute
> > a % is clearly wrong. IMHO some better guidelines as to what "Link
> > Quality" in WEXT should mean is desirable. borrowing definitions from
> > Joshua Bardwell in
> > http://www.connect802.com/download/techpubs/2004/you_believe_D100201.pdf,  
> > from a practical point of view "Signal Quality," though desirable as
> > link quality, is probably not feasible to get a handle on with the
> > (current and future) drivers. next best is probably "Signal Strength" -
> > from the RSSI values. Or is SNR better as a measurement of link quality?
> > but that would require a better reporting of noise by the drivers (and
> > not just a hardcoding) .
> 
> RSSI is totally manufacturer dependent.  AFAIK, Cisco uses a MAX_RSSI of
> 63 for the 340/350, Atheros uses something like 30, etc.  It depends on
> how many voltage values the hardware can physically measure.  So yes,
> you do get a sort of Link Quality % when you take RSSI / MAX_RSSI * 100.
> You can (and should) augment this value with things like the ipw2200
> driver does, ie receive packet errors, link speed, etc.
> 
> Converting RSSI to dBm and using that for link quality is actually
> pretty wrong.  dBm is actually useful though, you can do some
> interesting things with it like 1) distance from transmitter (if you
> know detailed antenna and card characteristics), 2) signal power levels
> and noise levels, 3) more accurately test different antennas, etc.  Its
> just not useful for getting a Link Quality % of any accuracy whatsoever,
> except when the Signal approaches the Noise you know your reception is
> starting to suck.
> 
> So 4 points to take out of this:
> 1) Drivers SHOULD use subjective values for calculating Quality, but
> that value SHOULD include some sort of RSSI measurement in addition to
> whatever else (ie invalid packets, retransmit count, link speed, etc)
> 2) Drivers SHOULD set both current level (ie qual.qual, qual.level) and
> max level (max_qual.qual, max_qual.level)
> 3) Drivers SHOULD use same units for level & noise (ie, either RSSI or
> dBm)
> 4) Drivers SHOULD use dBm wherever they can, if they can.
> 
> Dan

	Yes, Dan got the philosophy of the API pretty much spot
on. The qual.qual is the "feel good" number for most of us, the
qual.level is the measurable characteristics of the radio for the
engineers amongst us, and that explain why the API has both. Only when
you try to have a single measurement you have such a dilemma, but
because we already have qual.level, we are free to be totally
subjective with qual.qual.
	I'm personally happy with qual.qual to be driver specific, and
to evolve over time, as long as it give the maximum of feedback to the
user about the link performance. Note that users also have different
thresholds about acceptable performance, mostly based on the
applications they are using (FTP versus VoIP), so they will calibrate
themselves on those numbers.

> > "  Signal quality  is defined very briefly in 802.11. Common definitions
> > have arisen, but they are usually incorrect. The correct definition
> > hinges on the term,  PN code correlation strength,  which is a measure
> > of the match (correlation) between the incoming DSSS signal and an ideal
> > DSSS signal.

	Believe it or not, the obsolete Wavelan driver (pre 802.11)
uses exactly that as qual.qual. However, this definition only work for
true DSSS modulations, which means only for 1 and 2 Mb/s, which means
it's pretty much useless.
	I'm sure that for OFDM you could have a measure of quality
based on the pilot symbols, but that would only work for OFDMs bit
rates.

> > "  Signal to noise ratio  is a general term that is used in a novel way
> > by 802.11 administrators. Most usages of the term refer to the strength
> > of the signal relative to thermal noise within a circuit, but 802.11
> > administrators use the term to refer to the strength of the signal at
> > the receive antenna relative to the ambient, non-802.11 RF energy at the
> > same frequency as the signal. While this definition isn t wrong, per se,
> > it may lead to confusion when 802.11 administrators communicate with
> > engineers who are using the more traditional definition.

	Note that the Wireless Extensions never use any SNR, but use
signal and noise as separate measures. I agree with the article, the
signal and the noise are not measured in the same time and in the same
conditions, so are only loosely related.

	Have fun...

	Jean