[PATCH] Setting quality in scan results

[Matt Brown]

Contains an earlier response that I forgot to copy to the list as well.
Sorry :(

On Thu, 2004-04-22 at 17:15, Pavel Roskin wrote:
> On Thu, 22 Apr 2004, Matt Brown wrote:

> > If my understanding of the situation is correct, this will return a
> > different value to what the card calculates when it returns quality
> > results? This would lead to a potentially confusing situation where the
> > scan gives a different quality to actual operation.
> 
> Those values are not supposed to be compared.  Scanning is done at the
> lowest rate 1 Mbps.  Connections operate at up to 11 Mbps.  Higher rates
> are more sensitive to low signal-to-noise ratio.

A good point, something I had not considered.

> Also, the formula used by the firmware to calculate quality is not
> documented.  It's possible that the firmware uses data unavailable to the
> driver.

Yes, something I'm painfully aware of.

> What is supposed to be compared is the quality of different access points
> in the scan results.  Suppose one access point has a strong signal but the
> noise is high on the channel.  Another access point has a weaker signal,
> but the channel is relatively noise-free.  Which one is better?  iwlist
> always wants the driver to decide.  This is a design flaw in wireless
> tools, but we have to deal with it.

I guess, my concern is that I scan and select a network which appears to
have a good quality. I then select that network and the quality that I
am now observing is different to that which I saw on the scan. This
could lead to confusion.

>From your explanation above it seems probable that this will happen
anyway, so perhaps my concern is not valid.

> > > iwe.u.qual.updated is not used for scan results, but it's better not to
> > > return a random number from the kernel to the userspace.
> >
> > I agree, but why not return 0 to indicate that quality results are not
> > available during a scan.
> 
> Do you mean iwe.u.qual.updated or iwe.u.qual.qual?  iwe.u.qual.updated
> will be 0, it's in the patch.  Setting iwe.u.qual.qual to 0 would confuse
> users and possibly some utilities as well.  It's better to return some
> kind of quality data.

Not sure, I'm not familiar with the internals of this stuff yet, I was
thinking at a higher level.

My thinking as I was writing this email was that the scan data would
usually be used by an application (or the wireless tools) to
automatically pick the best network available. In this case you can
leave it up to the application to calculate a quality value from the
available signal and noise values. This was why I suggested setting the
quality to 0 as a clear indication that it has not been set. I didn't
really consider the case of users manually initiating a scan - I
wouldn't think it would be done very often and only by power users, it's
not a very friendly interface. 

This approach has several advantages to my mind.
- Confusion is avoided by not returning quality statistics derived from
different algorithms.
- The scan results to my mind are primarily intended for other
applications.
- The quality value is being generated by an arbitrary algorithm, best
to leave this to an application rather than a driver which should
provide a general interface.

I guess at the end of the day, it's a fairly minor point that I'm
raising.

Regards

-- 
Matt Brown
Email: matt at mattb.net.nz
GSM  : 021 611 544