bcm43xx-softmac: Further improvement in wireless statistics

PATCH In review Larry Finger 3 participants 7 messages Jul 11, 2006 – Jul 14, 2006

Subsystems (3)

Networking Network drivers Networking drivers (wireless)

lore

Share & tools

lore

Larry Finger

author

2006-07-11 16:05 UTC #0 lore raw

PATCH 1/1 bcm43xx-softmac: Further improvement in wireless statistics

This minor patch adjusts the parameters of the wireless statistics to improve the display of programs such as the "Wireless Network Information" applet of KDE.

Signed-off-by Larry Finger <[email protected]>

==============================================================

drivers/net/wireless/bcm43xx/bcm43xx_wx.c +3 -3

index 8ffd760..1ea04da 100644
@@ -49,7 +49,7 @@ #define BCM43xx_WX_VERSION	18
 #define MAX_WX_STRING		80
 /* FIXME: the next line is a guess as to what the maximum value of RX power
           (in dBm) might be */
-#define RX_POWER_MAX		-10
+#define RX_POWER_MAX		-20
 
 
 static int bcm43xx_wx_get_name(struct net_device *net_dev,

@@ -231,8 +231,8 @@ static int bcm43xx_wx_get_rangeparams(st
 
 	range->max_qual.qual = 100;
 	/* TODO: Real max RSSI */
-	range->max_qual.level = 0;
-	range->max_qual.noise = 0;
+	range->max_qual.level = -100;
+	range->max_qual.noise = -100;
 	range->max_qual.updated = IW_QUAL_ALL_UPDATED;
 
 	range->avg_qual.qual = 50;

Dan Williams

2006-07-11 19:32 UTC #1 lore raw

Quoted 23 lines · Larry Finger

This minor patch adjusts the parameters of the wireless statistics to improve the display of programs such as the "Wireless Network Information" applet of KDE.
Signed-off-by Larry Finger <[email protected]>
==============================================================
drivers/net/wireless/bcm43xx/bcm43xx_wx.c +1 -1
index 8ffd760..1ea04da 100644
@@ -49,7 +49,7 @@ #define BCM43xx_WX_VERSION	18
  #define MAX_WX_STRING		80
  /* FIXME: the next line is a guess as to what the maximum value of RX power
            (in dBm) might be */
-#define RX_POWER_MAX		-10
+#define RX_POWER_MAX		-20
 
 
  static int bcm43xx_wx_get_name(struct net_device *net_dev,

drivers/net/wireless/bcm43xx/bcm43xx_wx.c static int bcm43xx_wx_get_rangeparams(st · line 236

Quoted 8 lines

drivers/net/wireless/bcm43xx/bcm43xx_wx.c +2 -2

@@ -231,8 +231,8 @@ static int bcm43xx_wx_get_rangeparams(st
 
  	range->max_qual.qual = 100;
  	/* TODO: Real max RSSI */
-	range->max_qual.level = 0;
-	range->max_qual.noise = 0;
+	range->max_qual.level = -100;
+	range->max_qual.noise = -100;
  	range->max_qual.updated = IW_QUAL_ALL_UPDATED;

NAK... remember, range->max_qual.level must be _0_ if you're in dBm, since 0 is the actual maximum, and your level values are negative since they are in dBm.

If KDE network applets display the wrong value when max_qual.level == 0, then they are wrong and need to be fixed.

If you actually want RSSI, then you set max_qual.level to the upper limit of your RSSI, and the RSSI is assumed to go from 0 -> max_qual.level. AFAIK, the patch you had earlier is using dBm, _not_ RSSI, so max_qual.level = 0 is correct.

Dan

Quoted 5 lines

drivers/net/wireless/bcm43xx/bcm43xx_wx.c +0 -1
  	range->avg_qual.qual = 50;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Larry Finger

author

2006-07-12 04:04 UTC #2 lore raw

Quoted 2 lines · Dan Williams

NAK... remember, range->max_qual.level must be _0_ if you're in dBm,

I do not think this is right. From the comments in include/linux/wireless.h:

/* 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... */

My interpretation of this is that if 0 < max_qual < 128, the quantity is absolute. Conversely, if -129 < max_qual < 0, the quantity is in dBm. This is in fact what I see, both from the KDE applets and the various wireless extension tools.

Quoted 5 lines

since 0 is the actual maximum, and your level values are negative since they are in dBm.
If KDE network applets display the wrong value when max_qual.level == 0, then they are wrong and need to be fixed.

They display correctly; however, choosing 0 rather than -100 expands the scale to the point that my noise values of -65 dBm display as rather high values. Despite the 8-bit arithmetic, I think it creates a scale from 0 to -255 dBm. My choice of parameters expands the scale by limiting the lower value to -100 dBm.

Quoted 4 lines

If you actually want RSSI, then you set max_qual.level to the upper limit of your RSSI, and the RSSI is assumed to go from 0 -> max_qual.level. AFAIK, the patch you had earlier is using dBm, _not_ RSSI, so max_qual.level = 0 is correct.

As I explained earlier, the RSSI value returned by the firmware has been processed by the driver into a quantity that varies between -10 and -65 as the receiver is moved from very close to very far from the AP, which looks like strength in dBm. This is what is stored in stats.rssi. As this seems to be confusing, I will rewrite the driver code so that this value is returned in stats.signal with the RSSI value preserved in stats.rssi. The quality output will be derived from stats.rssi, and the level output will come from stats.signal. These two quantities have a correlation of -1 so there is no new information, but that might change in the future.

Larry

Dan Williams

2006-07-14 03:39 UTC #3 lore raw

Quoted 11 lines · Larry Finger

Quoted 2 lines · Dan Williams
NAK... remember, range->max_qual.level must be _0_ if you're in dBm,
I do not think this is right. From the comments in include/linux/wireless.h:
/* 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... */

Jean, what's the official word on range->max_qual.level?

I don't know where I came up with the requirement that max_qual.level must be 0 to indicate that the units are in dBm (as opposed to RSSI), but it might well have been because we had no way to detect RSSI vs. dBm before IW_QUAL_DBM was added as a flag in WE-19, and therefore using level = 0 was the only reliable way because 0 is the theoretical "max" level that most cards can handle.

So if you want to express your quality in dBm, you have a choice; either set IW_QUAL_DBM explicitly and do what you want with max_qual.level, or set your max_qual.level to 0. That's my interpretation, of course I could be wrong.

Furthermore, there's no point to setting your max_qual.level to be the lowest level, since that's what your max_qual.noise is!!! max_qual.noise is the noise floor of your card and that effectively _is_ the lowest level at which your card can operate.

In the ideal world, which we are now much closer to, we could _require_ that IW_QUAL_DBM was set, otherwise values would be interpreted as RSSI. And we can if the driver's we_source_version is >= 19. I agree, it's all quite confusing for starters.

Jean?

Quoted 7 lines

My interpretation of this is that if 0 < max_qual < 128, the quantity is absolute. Conversely, if -129 < max_qual < 0, the quantity is in dBm. This is in fact what I see, both from the KDE applets and the various wireless extension tools.
Quoted 3 lines
since 0 is the actual maximum, and your level values are negative since they are in dBm.

Quoted 7 lines

Quoted 2 lines
If KDE network applets display the wrong value when max_qual.level == 0, then they are wrong and need to be fixed.
They display correctly; however, choosing 0 rather than -100 expands the scale to the point that my noise values of -65 dBm display as rather high values. Despite the 8-bit arithmetic, I think it creates a scale from 0 to -255 dBm. My choice of parameters expands the scale by limiting the lower value to -100 dBm.

Hm, I didn't think that WE's quality specification took scale into account; AFAIK you get 255 values to play with, and each maps either to an RSSI value of your choice, or to an absolute dBm value. There's no scaling involved AFAIK.

Quoted 5 lines

Quoted 4 lines
If you actually want RSSI, then you set max_qual.level to the upper limit of your RSSI, and the RSSI is assumed to go from 0 -> max_qual.level. AFAIK, the patch you had earlier is using dBm, _not_ RSSI, so max_qual.level = 0 is correct.

Quoted 7 lines

As I explained earlier, the RSSI value returned by the firmware has been processed by the driver into a quantity that varies between -10 and -65 as the receiver is moved from very close to very far from the AP, which looks like strength in dBm. This is what is stored in stats.rssi. As this seems to be confusing, I will rewrite the driver code so that this value is returned in stats.signal with the RSSI value preserved in stats.rssi. The quality output will be derived from stats.rssi, and the level output will come from stats.signal. These two quantities have a correlation of -1 so there is no new information, but that might change in the future.

So; if you want to use dBm you should probably set IW_QUAL_DBM flag on the qual->updated field when you update level & noise. Then, nothing is ambiguous and everyone knows exactly what you mean. Which is why IW_QUAL_DBM was added, because I complained that quality was too ambiguous.

Jean?

Cheers,
Dan

Quoted 1 line

Larry

Larry Finger

author

2006-07-14 04:32 UTC #4 lore raw

Quoted 20 lines · Dan Williams

Jean, what's the official word on range->max_qual.level?
I don't know where I came up with the requirement that max_qual.level must be 0 to indicate that the units are in dBm (as opposed to RSSI), but it might well have been because we had no way to detect RSSI vs. dBm before IW_QUAL_DBM was added as a flag in WE-19, and therefore using level = 0 was the only reliable way because 0 is the theoretical "max" level that most cards can handle.
So if you want to express your quality in dBm, you have a choice; either set IW_QUAL_DBM explicitly and do what you want with max_qual.level, or set your max_qual.level to 0. That's my interpretation, of course I could be wrong.
Furthermore, there's no point to setting your max_qual.level to be the lowest level, since that's what your max_qual.noise is!!! max_qual.noise is the noise floor of your card and that effectively _is_ the lowest level at which your card can operate.

Quoted 4 lines

In the ideal world, which we are now much closer to, we could _require_ that IW_QUAL_DBM was set, otherwise values would be interpreted as RSSI. And we can if the driver's we_source_version is >= 19. I agree, it's all quite confusing for starters.

Setting IW_QUAL_DBM when updating does make /proc/net/wireless report level and noise as negative numbers. Thanks for pointing me in that direction.

I also tried both 0 and -100 as the qual_max values. The range is definitely better with -100 than with 0.

Larry

Jean Tourrilhes

2006-07-14 16:25 UTC #5 lore raw

In reply to Dan Williams

Quoted 13 lines · Dan Williams

Quoted 11 lines · Larry Finger
Quoted 2 lines · Dan Williams
NAK... remember, range->max_qual.level must be _0_ if you're in dBm,
I do not think this is right. From the comments in include/linux/wireless.h:
/* 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... */

Quoted 8 lines

Jean, what's the official word on range->max_qual.level?
I don't know where I came up with the requirement that max_qual.level must be 0 to indicate that the units are in dBm (as opposed to RSSI), but it might well have been because we had no way to detect RSSI vs. dBm before IW_QUAL_DBM was added as a flag in WE-19, and therefore using level = 0 was the only reliable way because 0 is the theoretical "max" level that most cards can handle.

I must admit that the original definition was too clever (or
too ambiguous, or too original, take your pick). range->max_qual.level is always supposed to have a meaningfull value. People that did not understand that original definition just put 0 there, as it was the easiest way to output dBm.
If you want more details, check the comment in the function
iw_print_stats() in iwlib.c.

	As I say, range->max_qual.level is always supposed to have

something useful, so :

if(IW_QUAL_DBM == 0)

	rssi level in the range [0 ; range->max_qual.level]
if(IW_QUAL_DBM == 1)
	(rssi level - 256) in the range [range->max_qual.level - 256 ; 0]

Quoted 4 lines

So if you want to express your quality in dBm, you have a choice; either set IW_QUAL_DBM explicitly and do what you want with max_qual.level, or set your max_qual.level to 0. That's my interpretation, of course I could be wrong.

Correct for WE>19.

Quoted 4 lines

Furthermore, there's no point to setting your max_qual.level to be the lowest level, since that's what your max_qual.noise is!!! max_qual.noise is the noise floor of your card and that effectively _is_ the lowest level at which your card can operate.

I did not think about that, and that's a very interesting
point. Yes, we could modify the definition to make use of that.

Quoted 6 lines

In the ideal world, which we are now much closer to, we could _require_ that IW_QUAL_DBM was set, otherwise values would be interpreted as RSSI. And we can if the driver's we_source_version is >= 19. I agree, it's all quite confusing for starters.
Jean?

I think WE-19 is old enough (most distro seems to use 2.6.16)
that we don't have to bother about earlier version going forward.

Quoted 4 lines

Hm, I didn't think that WE's quality specification took scale into account; AFAIK you get 255 values to play with, and each maps either to an RSSI value of your choice, or to an absolute dBm value. There's no scaling involved AFAIK.

You can use the full 255 values (but not 256). There is
scaling is you want you indicator to look nice with all cards.

Quoted 7 lines

So; if you want to use dBm you should probably set IW_QUAL_DBM flag on the qual->updated field when you update level & noise. Then, nothing is ambiguous and everyone knows exactly what you mean. Which is why IW_QUAL_DBM was added, because I complained that quality was too ambiguous.
Jean?

Correct.
And as pointed out later, it has the added bonus of having a
correct display of dBm in /proc/net/wireless.

Quoted 2 lines

Cheers,
Dan

Jean

Larry Finger

author

2006-07-14 17:09 UTC #6 lore raw

Jean,

Quoted 8 lines · Jean Tourrilhes

I must admit that the original definition was too clever (or
too ambiguous, or too original, take your pick). range->max_qual.level is always supposed to have a meaningfull value. People that did not understand that original definition just put 0 there, as it was the easiest way to output dBm.
If you want more details, check the comment in the function
iw_print_stats() in iwlib.c.

Quoted 7 lines

	As I say, range->max_qual.level is always supposed to have

something useful, so :

if(IW_QUAL_DBM == 0)

	rssi level in the range [0 ; range->max_qual.level]
if(IW_QUAL_DBM == 1)
	(rssi level - 256) in the range [range->max_qual.level - 256 ; 0]

Thank you for your explanation and the reference to the comment from wireless_tools. I think it is safe to say that we all have learned a lot. As you say, 8-bit arithmetic is tricky.

Quoted 2 lines

I think WE-19 is old enough (most distro seems to use 2.6.16)
that we don't have to bother about earlier version going forward.

I'm going to rely on that, set IW_QUAL_DBM, and choose the max_qual at 152, which corresponds to a floor-value of -104 dBm. The KDE applet display is a little strange as it displays -65 dBm at approximately 2/3 height, rather than the 1/3 value that I would expect. So far, I have not found the source for that applet and cannot verify the calculation. In any case, the display is acceptable even if not what I would expect. At least, the values in /proc/net/wireless are correct.

Thanks again,

Larry