Re: Changing Auto-Connect feature
- From: Franco Miceli <fmiceli plan ceibal edu uy>
- To: Dan Williams <dcbw redhat com>
- Cc: networkmanager-list gnome org
- Subject: Re: Changing Auto-Connect feature
- Date: Thu, 15 Jul 2010 10:04:39 -0300
Thank you so much for your answers. We've requested that the driver gets changed, since we don't have the resources to do it ourselves. We have yet to test the version that comes with the F11 build, but are confident that this mater gets solved.
Again, thanks for the feedback.
Cheers.
2010/7/14 Dan Williams
<dcbw redhat com>
On Thu, 2010-07-08 at 12:13 -0300, Franco Miceli wrote:
> Dan,
>
> Regarding the subject of autoconnection to a favourites list. The
> changes proposed by our team include not only changing the selection
> algorithm to the one you proposed, but also to change the way the
> strength is calculated.
>
> We've made tests on the XO's quality reports by the driver and have
> noticed that it has a bug where the tx_retries are never being reset.
> That's the reason for not choosing the Q that comes from the driver.
> In order to accomplish our goals in the autoconnection feature for the
> XO we've decided to choose a SNR type of measurement for the quality.
>
> As I've seen the method "wireless_qual_to_percent" is only used inside
> nm_device_wifi and in functions relating to updating and setting the
> value for the AP.
> Our goal is to modify as little as possible, while accomplishing our
> goals.
>
> I would really appreciate your feedback if you see any inconveniences
> in these changes.
Probably not, but you could also try to fix the driver to reset the
failed TX retries when it disconnects to the AP. Other than that, it's
probably an OK path to take.
Dan
> Thank you so much for your answers.
>
> Cheers,
>
> 2010/6/5 Dan Williams <
dcbw redhat com>
>
> On Thu, 2010-05-27 at 05:56 +0200, Frederik Nnaji wrote:
> > On Tue, May 25, 2010 at 18:45, Franco Miceli
> > <
fmiceli plan ceibal edu uy> wrote:
> > Therefore we want to to make some changes to the NM
> code in
> > order to take into consideration other factors such
> as: SNR,
> > loss %, etc.
> >
> >
> > will you considered working on a UI for manually selecting
> and
> > configuring a symbolic visual representation of known APs
> currently
> > within range/sight?
> > This would also help with GeoLocation, since it could use
> "strength"
> > to approximate My position by the nearness of a known AP
> currently
> > within sight.
>
>
> We've thought about strength for a while, but in the end it
> doesn't work
> very well. There are simply too many things that can affect
> AP signal
> strength to use it as a reliable measure of where you are.
> It's better
> to use *more than one* AP and triangulate to get better
> accuracy than
> just 100m radius of one AP's known location. Using only one
> AP, if
> somebody turns on a microwave or uses a 2.4GHz DECT phone,
> suddenly it
> looks like you're 30 meters farther away from the AP than you
> were 10
> seconds ago...
>
> Dan
>
>
>
>
> --
> Ing. Franco Miceli
> CITS - Plan Ceibal - Investigación & Desarrollo
> Av. Italia 6201 - Montevideo, Uruguay
> CP: 11500
> Tel: (598 2) 601 5773 int.: 2227
--
Ing. Franco Miceli
CITS - Plan Ceibal - Investigación & Desarrollo
Av. Italia 6201 - Montevideo, Uruguay
CP: 11500
Tel: (598 2) 601 5773 int.: 2227
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]