GNOME Bugzilla – Bug 119472
link quality computation ?
Last modified: 2011-07-10 02:43:46 UTC
Hello, Is there a documented reason to the way the link quality is computed ? (log (link) / log (92)) * 100.0 ? Shouldn't avg_qual and max_qual from wireless.h be used instead ?
92 seems to be a general recognized number for the max link by the companies but nothing more. I have a Netgear WG511, and its link quality at 100% is around 250, which makes this applet stuck on CLAMP (+100%), and therefore I patch the formula myself. If there is an avg_qual and max_qual, I hope it is considered.
We'd love to use the avg_qual and max_qual values from wireless.h, however I personally don't own a laptop, neither a wireless card so I since I won't be able to test it I'm not going to start on it either. Fabrice do you think you could possibly make a patch for this ?
Created attachment 29231 [details] [review] proposed patch to handle max_qual/avg_qual Hello, this patch adds a dependency with libiw from the wireless-tools. It computes a percentage on the two distinct intervals [0 .. avg_qual] and [avg_qual .. max_qual]. This idea is that the applet gives a 50% when the signal quality equals avg_qual. Note that _not_ all wireless drivers provide avg_qual. I tested on my prism2.5 card, with latest linux-wlan-ng driver : the avg value is 90, and the max value is 92, the min is implicitely 0. So the range is rather distorded. I checked in the linux-wlan-ng source code, and only max_qual is defined (with the expected value of 92). I don't know where the value of 90 comes from. This one should probably be considered as very unreliable. So, another possibility is to just care about the max_qual value, and to simply replace log(92) by log(max_link). Opinions ? BTW, why use a log() to compute a percentage ? Is the signal quality supposed to be in an exponential form ?
*** Bug 143560 has been marked as a duplicate of this bug. ***
Here's an interesting link on this topic: http://www.wildpackets.com/elements/whitepapers/Converting_Signal_Strength.pdf As far as I can make out, the current calculation is bogus and the link level is meaningless without the max_qual figure. However, looking at the code for various wireless cards they don't seem to report it at all. This is a giant mess, I'm not sure what to make of it all yet :/
Mark- you might want to poke Joe Shaw and Robert Love on this; they've both played around with this issue a bit lately.
Mark: you've got it pretty much right. In my experience with a handful of drivers it's generally pretty safe to assume around 92 for max_qual. The drivers that work at all seem to hover around that range. But a lot of drivers are just broken and report wildly varying numbers or, more commonly, 0. Like everything in the Linux wireless stack, it is a giant mess.
Hi everybody, Sorry to jump in the middle of the discussion ;-) IMHO, the patch Fabrice Bellet is the way forward and the only sane solution in the long term. Maybe you could ignore avg_qual at least until things settle. I personally see the problem as a chicken and egg problem. User space applications don't use max_qual/avg_qual, therefore driver authors can't test and don't bother with it, and consequently user space programmers can't rely on it. I also would like to see it as a two way street. Driver authors don't know a-priori what values would work best, especially for avg_qual. So, you guys should tell the driver guys what you want to make your applet work. It's actually fairly simple, the infrastructure is all there, we just need to plug the numbers. Take your favorite wireless driver, go around the coverage area, and check the qual indicator. Then, figure out what is the max and the average. Then, send a patch to the driver author (the patch is absolutely trivial). Bug him until he applies your patch in his driver. Repeat with the next driver. (For Mark) concerning Signal Strength conversion : This is exactly why the API defines both a synthetic value (qual - 0->max) and absolute values (level&noise, in dBm). With dBm, you can compare cards directly to each other without the need for the max (well, this assume that dBm calculation is done properly in the driver). On the other hand, qual was never supposed to be related to dBm, but you can convert it to % using the max_qual. So, the current API offer both solutions. Jean
I'm pretty sure Fedora have now deprecated this applet in preference to gnome-netstatus applet, I would like to follow suite in GNOME itself. There is no need for two wireless monitoring applets (really, gnome-netstatus doesn't need to be a separate module, but that's a different problem). How does gnome-netstatus deal with this problem?
gnome-netstatus uses the same formula and, hence, has the same problem
Since we are no longer shipping wireless-applet, I'm going to move this to gnome-netstatus. I was hoping to get more wireless love into g-netstatus this release cycle, but it's just not going to happen.
Created attachment 37840 [details] [review] add wireless link range in gnome-netstatus-2.9.4 . With this patch, the range is asked only one time in netstatus_iface_monitor_timeout(), when iface->priv->is_wireless becomes TRUE. . The standard range [0..92] is applied, if the avg value is zero, and the max value is okay (eg, madwifi driver). A more adaptive possibility would be to fall back to avg=max/2 in this case. . A more simple patch could also consist in querying the range each time netstatus_sysdeps_read_iface_wireless_details() is called. Cleaner code, but more ioctl() intensive :-(
*** Bug 150903 has been marked as a duplicate of this bug. ***
*** Bug 325952 has been marked as a duplicate of this bug. ***
*** Bug 162728 has been marked as a duplicate of this bug. ***
gnome-netstatus development has been stalled [1]. Maintainers don't have future development plan so i am closing the bugs as WONTFIX. [1] http://mail.gnome.org/archives/desktop-devel-list/2011-June/msg00073.html