hi jean! i really appreciate your input based on your experiences with the wireless extensions! On Thursday 27 March 2008 09:19:09 Jean Tourrilhes wrote: > Now, we would like all hardware to report RSSI in dBm, and get > done with it. i definetly agree with that. dBm is what we want! > However, some hardware (Atheros) can not do it, because > their RSSI hardware is uncalibrated. So, what do you do with those > hardware ? Reporting a "relative" signal strength is probably better > than nothing. can you explain why you think atheros HW is "relative"? in the past in madwifi RSSI was said to be measured against a fixed noise value of -95dBm (which should be expressed by using _SIGNAL_DB in my patch) but now we have a periodic noise floor calibration and we assume RSSI to be relative to that, so we believe to be able to provide dBm for both values. that's how it is currently reported in madwifi and ath5k and what we believe to be correct (without having much documentation from atheros, however) - if that's not correct we have to modify the drivers. > Note also that many hardware are not truly calibrated, but > "sort of" calibrated (Orinoco, HostAP). Good measurement is expensive, > that's why most implementation do measurement on the cheap. It means > the value will be correct within some few percents for a large part > range. Up to now, we pretented that those devices report dBm > properly. That's why RCPTI talk of expected accuracy of measurement. hmm, accuracy is another question. i think at the moment as long as the device tries to report dBm i would say it's dBm no matter what the accuracy is. in the future, when we know more about the devices we can add some hw flags or variables which can state that accuracy of the signal/noise measurements. > Clearly, you have to think hard and define is the reference is > fixed (as stated above) or variable (Atheros). The fixed reference > could be more useful to apps, but I don't know how many HW would fit > that definition. The variable reference would accomodate the Atheros > nicely. again, please tell us more about atheros. we believe RSSI to be relative to the noise floor, which we can measure. therefore we have dBm for both. > And of course, the main question to ask is, is this extra > functionality worth the additional complexity of the API, and the > potential confusion to users. I don't know, but for WE the answer was > no. sorry jean, no offense, but the usage of these values in WE was really confusing and the lack of knowing what the values acutally mean made it really hard for applications to work with them. i think it is worth the effort to make that clearer and explicity state the HW capabilities instead of using implicit mechanisms so applications can know more exactly what to expect. applications which would have benefits from that would include NetworkManager, roaming agents, link metric calculations for mesh networks,... > Note also that you may need an agregate measure of how good > the link is, but that would be best generated by the stack itself. I > guess for most devices, the bitrate in use will tell you that kind of > information. once we have the signal units properly specified by the HW we can and should do things like this in mac80211 - i think we should move the "qual" link quality calculation up into mac80211 so it will be the same for all devices. > > > + * > > > + * @IEEE80211_HW_SIGNAL_UNSPEC: > > > + * Hardware can provide signal values but we don't know its > > > units. To be + * able to standardize between different devices we > > > would like linear + * values from 0-100. If possible please provide > > > dB or dBm instead. > > Note that for some hardware, you can not get liner values (see > above). ok, good point! i think we should remove that from the definition then. > Anyway, what does linear means, is it linear on a log/dBm > scale or on a power/mW scale ? linear would mean linar on whatever units the device uses (might be a power/mW scale). log/dBM i would call "logarithmic". but anyhow, as you said not all devices can do linear, so i would tend to remove that from the definition and just say "totally unspecified". if the need arises we could invent 2 different flags like IEEE80211_HW_SIGNAL_UNSPEC_LOG and IEEE80211_HW_SIGNAL_UNSPEC_LINEAR but i think that would be overkill right now. > > > + * @IEEE80211_HW_NOISE_DBM: > > > + * Hardware can provide noise floor values in units dBm, decibel > > > difference + * from one milliwatt. > > Noise only defined in dBm ? Some older devices have noise in > "unspec". I also don't know what Atheros does here. so far as far as i can see drivers either know the noise in dBm or don't know it at all. if there is HW which has "unspec" we can add that. bruno -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
