mac80211 and drivers: Improve wireless statistics

In wireless statistics reporting, three quantities related to the signal are reported: "qual" (linear with the signal), "level" (logarithmic), and "noise". In mac80211 and the drivers that use it, the first two have a mixture of internal names for those quantities. To reduce confusion, this series of patches make the internal names match the entity that is being kept.

So that any bisection of the source will always result in code that will compile, the patches are divided as follows:

1/4: The new names are added to the appropriate struct definitions in mac80211. 2/4: The mac80211 routines are modified to use the new names.
3/4: The drivers that use mac80211 are modified.
4/4: The old names are removed from the struct definitions.

These changes assume the prior application of patches "[PATCH] mac80211: remove redundant rssi information in scan results" by Michael Wu and "[PATCH] mac80211: Report correct wireless statistics" by Larry Finger.

---

Those are really bad names.
__signal__ is not meaning a value __signal level__ or __signal strength__ means value
__level__ is too general to describes anything
RSSI on other hand is well defined. Maybe it's too hw/vendor dependent to use in stack
but at least its names says what it is.
Quality should be a relative number depends on maxim
I don't think this renaming make things clearer
Tomas

Perhaps my names are bad; however, the existing system is broken. With it, passing the rssi value and the signal strength from bcm43xx-mac80211 results the following output from iwconfig: "Link Quality=216/146 Signal level=-197 dBm Noise level=-63 dBm". In bcm43xx-softmac, the code in the driver is identical and results in "Link Quality=90/100 Signal level=-36 dBm Noise level=-69 dBm".

When I proposed a patch to fix mac80211, Michael Wu NACKed it and requested the name changes I propose here. I don't care what names things get, but it needs to be fixed!

Larry

If you don't care what names things get, then my patch which swaps signal and rssi assignment in bcm43xx-mac80211 is fine. If you don't like that, then you do care.

I think "level" isn't very intuitive for a number that's either RSSI or dBm, however. I recommended "signal" instead which seems to better suggest a measure of signal strength/level, at least until we come up with a better statistics reporting system in cfg80211.

-Michael Wu

Yeah, I wasn't much constructive in my critique
So here is my humble suggestion. I suggesting not to kill rssi. u8 rssi (signal is already in rSsi)
s8 signal_level (always in dBm)
s8 signal_noise
u8 link_qual

rssi should stay rssi and its range is from 0 to 255 i.e. one byte. 0 means no signal
and maximal value should be set by underlying driver.

signal_level is in dBm.
There should not be mixing between signal_level and rssi as it is now in wext. 'man iwconfig'
rssi - Received signal strength (RSSI - how strong the received signal is). May be arbitrary units or dBm,

The confusion comes from fact that
signal_level (dBm) is usually computed by some magic equation from RSSI but they are not the same.
In general wext should be interested only in dBm values for 'Signal Level'

Link quality computation should be left to underlying driver as it is totally hw dependent and may includes different parameters that are hard to generalize in subsystem level.
It should be equal neither to rssi nor to signal level.

The only reason to keep also rssi is that it's necessary for the underlying driver and it's easier and to compute with.

As you can see the in the code it self the intention of wext was just that.

/*
* Quality of the link
*/
struct iw_quality
{
__u8 qual; /* link quality (%retries, SNR,
%missed beacons or better...) */
__u8 level; /* signal level (dBm) */
__u8 noise; /* noise level (dBm) */
__u8 updated; /* Flags to know if updated */
};

The whole signal reporting in WE looks like a mess to me. It seems that no renaming could help here, I'm afraid - the names you consider better others consider worse.

Let's leave it as is, and return to it when converting mac80211 to use cfg80211. With a bit of luck it would be no issue then :-)

Thanks,

Jiri

Jiri Benc
SUSE Labs

I have already decided to leave the whole mess alone. I will patch bcm43xx-mac80211 to conform to what is currently in mac80211 so that reasonable values are seen by the users.

Larry