dBm cutoff at -1dBm is too low

dBm cutoff at -1dBm is too low

[Pavel Roskin]

Hello, Jean!

I'm converting Orinoco to the dBm reporting, and it turns out that the
best signal iwconfig will report is -1dBm (0.8mW).  This would happen if
qual->level has its highest value of 255.  Please see this code from
wireless_tools.29.pre10:

len = snprintf(buffer, buflen, "Signal level%c%d dBm  ",
               qual->updated & IW_QUAL_LEVEL_UPDATED ? '=' : ':',
               qual->level - 0x100);

With most cards transmitting at 100mW and some going as high as 500mW,
it's not unreasonable to expect that the received signal may exceed 1mW
for closely located receivers with good antennas.  I have seen HostAP
reporting as much as 3mW through the proc filesystem!

Wouldn't it be better to put the cutoff at a higher value?  The simplest
approach would be to treat qual->level and qual->noise as signed char,
which would put the cutoff and 127dBm.  500 gigawatts should be enough
for everyone :-)

-- 
Regards,
Pavel Roskin

Re: dBm cutoff at -1dBm is too low

[Jean Tourrilhes]

On Thu, May 04, 2006 at 12:37:45PM -0400, Pavel Roskin wrote:
> Hello, Jean!
> 
> I'm converting Orinoco to the dBm reporting, and it turns out that the
> best signal iwconfig will report is -1dBm (0.8mW).  This would happen if
> qual->level has its highest value of 255.  Please see this code from
> wireless_tools.29.pre10:
> 
> len = snprintf(buffer, buflen, "Signal level%c%d dBm  ",
>                qual->updated & IW_QUAL_LEVEL_UPDATED ? '=' : ':',
>                qual->level - 0x100);

	Yes, that's correct.
	Note that the main limitation is that before I introduced the
explicit IW_QUAL_DBM in WE-19, the way to know if the value was
relative or dBm was to use the 'sign' of it, i.e. value above 0 were
non-dBm. The test is a few line before this snipset :

---------------------------------------------------------
      /* Check if the statistics are in dBm or relative */
      if((qual->updated & IW_QUAL_DBM)
	 || (qual->level > range->max_qual.level))
	{
---------------------------------------------------------

	There are still quite a few drivers which have not been
converted to use IW_QUAL_DBM, so I don't want to drop the backward
compatibility yet.

> With most cards transmitting at 100mW and some going as high as 500mW,
> it's not unreasonable to expect that the received signal may exceed 1mW
> for closely located receivers with good antennas.  I have seen HostAP
> reporting as much as 3mW through the proc filesystem!

	My rationale was two fold.
	First, such high values are quite unlikely, because cards need
to be very close, which does not happen that often. Power is limited
by spec and power consumption, so unlikely to go higher than
this. Also, I'm surprised that the card receiver does not saturate
with such high receive power, but I would question the accuracy of the
measurement.
	Second, the measurement is useful mostly in marginal
conditions. When signal is great, you don't really care, when signal
is low, you want to tweak your system to improve reception.

> Wouldn't it be better to put the cutoff at a higher value?  The simplest
> approach would be to treat qual->level and qual->noise as signed char,
> which would put the cutoff and 127dBm.  500 gigawatts should be enough
> for everyone :-)

	FCC says Tx 1W @ 2.4 GHz, ETSI says Tx 100mW @ 2.4 Gz. Yeah,
you could use directional antennas. So, realistically, we only need to
extend to +30dBm.
	On the other hand, I expect that with MIMO and UWB we would
start to receive signal weaker than what we currently do, and you
don't want to cutoff the bottom of the range (is -128dBm enough ?).
	I tried to use 'signed' in the struct a long while ago, and
for some reason it broke left and right, I don't remember the
details. So, whatever we do, it would not be straightforward.

> Regards,
> Pavel Roskin

	Have fun...

	Jean

Re: dBm cutoff at -1dBm is too low

[Pavel Roskin]

On Fri, 2006-05-05 at 10:28 -0700, Jean Tourrilhes wrote:
> 	Note that the main limitation is that before I introduced the
> explicit IW_QUAL_DBM in WE-19, the way to know if the value was
> relative or dBm was to use the 'sign' of it, i.e. value above 0 were
> non-dBm. The test is a few line before this snipset :
> 
> ---------------------------------------------------------
>       /* Check if the statistics are in dBm or relative */
>       if((qual->updated & IW_QUAL_DBM)
> 	 || (qual->level > range->max_qual.level))
> 	{
> ---------------------------------------------------------
> 
> 	There are still quite a few drivers which have not been
> converted to use IW_QUAL_DBM, so I don't want to drop the backward
> compatibility yet.

But shouldn't you trust the drivers using IW_QUAL_DBM, whether the value
is positive or negative?

> 	Second, the measurement is useful mostly in marginal
> conditions. When signal is great, you don't really care, when signal
> is low, you want to tweak your system to improve reception.

The problem is the driver has to take care of it.  It cannot just take
the dBm value from the card and pass it to userspace.  It has to limit
the value at -1.  Otherwise iwconfig would show -256dBm or something
like that.  I can imagine that some GUI can decide that the connection
has become very bad, and that would confuse the user.

> > Wouldn't it be better to put the cutoff at a higher value?  The simplest
> > approach would be to treat qual->level and qual->noise as signed char,
> > which would put the cutoff and 127dBm.  500 gigawatts should be enough
> > for everyone :-)
> 
> 	FCC says Tx 1W @ 2.4 GHz, ETSI says Tx 100mW @ 2.4 Gz. Yeah,
> you could use directional antennas. So, realistically, we only need to
> extend to +30dBm.
> 	On the other hand, I expect that with MIMO and UWB we would
> start to receive signal weaker than what we currently do, and you
> don't want to cutoff the bottom of the range (is -128dBm enough ?).
> 	I tried to use 'signed' in the struct a long while ago, and
> for some reason it broke left and right, I don't remember the
> details. So, whatever we do, it would not be straightforward.

I suggest -192dBm to 63dBm.  That's enough padding on both sides, so
that the drivers can just pass the firmware value without checking.

-- 
Regards,
Pavel Roskin

Re: dBm cutoff at -1dBm is too low

[Jean Tourrilhes]

On Sat, May 06, 2006 at 11:32:12PM -0400, Pavel Roskin wrote:
> On Fri, 2006-05-05 at 10:28 -0700, Jean Tourrilhes wrote:
> > 
> > 	There are still quite a few drivers which have not been
> > converted to use IW_QUAL_DBM, so I don't want to drop the backward
> > compatibility yet.
> 
> But shouldn't you trust the drivers using IW_QUAL_DBM, whether the value
> is positive or negative?

	You can't remove the test, making the rest pointeless. Old
style driver never used the flags, new style driver that don't report
dBm will never use the flags, and there is not way to dinstinguish
both, apart from the 'sign' of the value.
	We may want to perform an audit of the various drivers,
in-tree and out-of-tree, to see how much progress we have made so far.

> The problem is the driver has to take care of it.  It cannot just take
> the dBm value from the card and pass it to userspace.  It has to limit
> the value at -1.  Otherwise iwconfig would show -256dBm or something
> like that.  I can imagine that some GUI can decide that the connection
> has become very bad, and that would confuse the user.

	Correct.

> I suggest -192dBm to 63dBm.  That's enough padding on both sides, so
> that the drivers can just pass the firmware value without checking.

	Yep, seems reasonable.

> Pavel Roskin

	Jean

Re: dBm cutoff at -1dBm is too low

[Pavel Roskin]

On Mon, 2006-05-08 at 10:17 -0700, Jean Tourrilhes wrote:
> > But shouldn't you trust the drivers using IW_QUAL_DBM, whether the value
> > is positive or negative?
> 
> 	You can't remove the test, making the rest pointeless. Old
> style driver never used the flags, new style driver that don't report
> dBm will never use the flags, and there is not way to dinstinguish
> both, apart from the 'sign' of the value.

I used "new style driver" as synonymous to the driver using IW_QUAL_DBM
and "old style driver" as the one that doesn't use IW_QUAL_DBM.

I don't think any drivers need to specify both dBm and non-dBm data for
the same device.

Drivers that give non-dBm data are already well served by wireless
tools.  They don't need to change.

Drivers that give dBm data had to limit the data to avoid its
misinterpretation as non-dBm data.  Now IW_QUAL_DBM is supposed to free
drivers from such checks.  But it doesn't deliver its promise, because
the data can still be misinterpreted, just is a different way.  Namely,
a strong signal (0dBm) can be interpreted as an incredibly weak signal
(-256dBm).  That's what I want to see fixed.

One tricky case would be when the driver sets the max signal e.g. to 30
and reports 35 (i.e. a positive value within the "reasonable" dBm
range).  I would probably prefer to show it as 30/30 rather than 35dBm,
but the driver is nuts anyway, and I'm not really concerned about it to
write an extra line of code.

-- 
Regards,
Pavel Roskin

Re: dBm cutoff at -1dBm is too low

[Jean Tourrilhes]

On Tue, May 09, 2006 at 12:54:55AM -0400, Pavel Roskin wrote:
> On Mon, 2006-05-08 at 10:17 -0700, Jean Tourrilhes wrote:
> > > But shouldn't you trust the drivers using IW_QUAL_DBM, whether the value
> > > is positive or negative?
> > 
> > 	You can't remove the test, making the rest pointeless. Old
> > style driver never used the flags, new style driver that don't report
> > dBm will never use the flags, and there is not way to dinstinguish
> > both, apart from the 'sign' of the value.
> 
> I used "new style driver" as synonymous to the driver using IW_QUAL_DBM
> and "old style driver" as the one that doesn't use IW_QUAL_DBM.
> 
> I don't think any drivers need to specify both dBm and non-dBm data for
> the same device.
> 
> Drivers that give non-dBm data are already well served by wireless
> tools.  They don't need to change.
> 
> Drivers that give dBm data had to limit the data to avoid its
> misinterpretation as non-dBm data.  Now IW_QUAL_DBM is supposed to free
> drivers from such checks.  But it doesn't deliver its promise, because
> the data can still be misinterpreted, just is a different way.  Namely,
> a strong signal (0dBm) can be interpreted as an incredibly weak signal
> (-256dBm).  That's what I want to see fixed.

	I hear you 100%. But, before removing the backward
compatibility for old style drivers, we need to make sure all of them
are gone. I don't plan to keep backward compatibility forever, but
just enough to cover the transition.
	Technically, we can't make backward compatibility for old
driver and this proposal to work together, because of the test on the
sign. We need to pick one.

> One tricky case would be when the driver sets the max signal e.g. to 30
> and reports 35 (i.e. a positive value within the "reasonable" dBm
> range).  I would probably prefer to show it as 30/30 rather than 35dBm,
> but the driver is nuts anyway, and I'm not really concerned about it to
> write an extra line of code.

	Agreed.

> Regards,
> Pavel Roskin

	Jean

Re: dBm cutoff at -1dBm is too low

[Pavel Roskin]

On Fri, 2006-05-05 at 10:28 -0700, Jean Tourrilhes wrote:
> 	I tried to use 'signed' in the struct a long while ago, and
> for some reason it broke left and right, I don't remember the
> details. So, whatever we do, it would not be straightforward.

Then let's keep the structure as is and change what iwconfig is
displaying:

--- iwlib.c
+++ iwlib.c
@@ -1400,7 +1400,7 @@ iw_print_stats(char *		buffer,
 	    {
 	      len = snprintf(buffer, buflen, "Signal level%c%d dBm  ",
 			     qual->updated & IW_QUAL_LEVEL_UPDATED ? '=' : ':',
-			     qual->level - 0x100);
+			     ((qual->level - 192) & 0xff) + 192);
 	      buffer += len;
 	      buflen -= len;
 	    }

Semantically, it's already nonsense to use an unsigned number for a
value that is almost always negative.  The true meaning of qual->level
is already a subject of convention.  So let's just adjust this
convention so that we don't punish the clients that report valid
positive dBm values.

The client calculates a value (perhaps an integer) and pushes it into
unsigned char in the hope that the client side can understand it using
the common sense.  Interpreting 0dBm as -256dBm goes against the common
sense.  This has to be specifically worked around in the drivers.

Of course, it would be nice to document it somewhere, and to have
constants e.g.

#define DBM_MIN -192
#define DBM_MAX 63

-- 
Regards,
Pavel Roskin