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

Reply via email to