netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: jt@hpl.hp.com
Cc: NetDev <netdev@vger.kernel.org>
Subject: Re: dBm cutoff at -1dBm is too low
Date: Sat, 06 May 2006 23:32:12 -0400	[thread overview]
Message-ID: <1146972732.24434.89.camel@dv> (raw)
In-Reply-To: <20060505172818.GA7543@bougret.hpl.hp.com>

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


  reply	other threads:[~2006-05-07  3:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-04 16:37 dBm cutoff at -1dBm is too low Pavel Roskin
2006-05-05 17:28 ` Jean Tourrilhes
2006-05-07  3:32   ` Pavel Roskin [this message]
2006-05-08 17:17     ` Jean Tourrilhes
2006-05-09  4:54       ` Pavel Roskin
2006-05-09 18:54         ` Jean Tourrilhes
2006-05-08  3:35   ` Pavel Roskin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1146972732.24434.89.camel@dv \
    --to=proski@gnu.org \
    --cc=jt@hpl.hp.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).