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 _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list