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 ([EMAIL PROTECTED]): > > (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 > _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list