From: Larry Finger <Larry.Finger@lwfinger.net>
To: Dan Williams <dcbw@redhat.com>
Cc: John Linville <linville@tuxdriver.com>, netdev@vger.kernel.org
Subject: Re: [PATCH] bcm43xx-softmac: Further improvement in wireless statistics
Date: Tue, 11 Jul 2006 23:03:59 -0500 [thread overview]
Message-ID: <44B474AF.6010907@lwfinger.net> (raw)
In-Reply-To: <1152646370.27683.2.camel@localhost.localdomain>
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
next prev parent reply other threads:[~2006-07-12 4:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-11 16:04 [PATCH] bcm43xx-softmac: Further improvement in wireless statistics Larry Finger
2006-07-11 19:32 ` Dan Williams
2006-07-12 4:03 ` Larry Finger [this message]
2006-07-14 3:37 ` Dan Williams
2006-07-14 4:32 ` Larry Finger
2006-07-14 16:25 ` Jean Tourrilhes
2006-07-14 17:09 ` Larry Finger
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=44B474AF.6010907@lwfinger.net \
--to=larry.finger@lwfinger.net \
--cc=dcbw@redhat.com \
--cc=linville@tuxdriver.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).