[PATCH] bcm43xx-softmac: Further improvement in wireless statistics

[PATCH] bcm43xx-softmac: Further improvement in wireless statistics

[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 <Larry.Finger@lwfinger.net>

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



diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
index 8ffd760..1ea04da 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -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;

Re: [PATCH] bcm43xx-softmac: Further improvement in wireless statistics

[Dan Williams]

On Tue, 2006-07-11 at 11:04 -0500, Larry Finger wrote:
> 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 <Larry.Finger@lwfinger.net>
> 
> ==============================================================
> 
> 
> 
> diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
> index 8ffd760..1ea04da 100644
> --- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
> +++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
> @@ -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;

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

>   	range->avg_qual.qual = 50;
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcm43xx-softmac: Further improvement in wireless statistics

[Larry Finger]

Dan Williams wrote:
> 
> 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.

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

> 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

Re: [PATCH] bcm43xx-softmac: Further improvement in wireless statistics

[Dan Williams]

On Tue, 2006-07-11 at 23:03 -0500, Larry Finger wrote:
> Dan Williams wrote:
> > 
> > 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?

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

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.

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

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

> Larry

Re: [PATCH] bcm43xx-softmac: Further improvement in wireless statistics

[Larry Finger]

Dan Williams wrote:
> 
> 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.

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

Re: [PATCH] bcm43xx-softmac: Further improvement in wireless statistics

[Jean Tourrilhes]

On Thu, Jul 13, 2006 at 11:37:45PM -0400, Dan Williams wrote:
> On Tue, 2006-07-11 at 23:03 -0500, Larry Finger wrote:
> > Dan Williams wrote:
> > > 
> > > 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.

	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]

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

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

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

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

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

> Cheers,
> Dan

	Jean

Re: [PATCH] bcm43xx-softmac: Further improvement in wireless statistics

[Larry Finger]

Jean,

Jean Tourrilhes wrote:
> 
> 	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]

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.

> 	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