GNOME Bugzilla – Bug 732651
increase scanning frequency when network selection dialog shown
Last modified: 2016-06-27 15:43:40 UTC
The experience of using GNOME with wifi is substantially worse than android in terms of responsiveness. In particular, it often takes an extremely long time for networks to appear (for example, after enabling the hotspot on my phone). This is caused by infrequent scanning which is done to save power, but also to reduce interruptions in connectivity while connected (since the radio has to change channels to scan). One clear place that the scanning should be increased is when the network selection dialog is open. I talked to Dan about this today and he wrote this proof of concept patch: http://bigw.org/~dan/rescan.patch In addition to that, we discussed that we often have a problem that networks stay in NM's list for far too long after they were last seen. The idea is to move toward expiring them out of the cache after a certain number of rescans has occurred. Unfortunately, this might result in this strange experience: 1) get on a tram and open laptop 2) travel for a bit, picking up networks on the way 3) networks don't get expired because of long period between scans 4) open network selection dialog -- scan frequency is massively increased 5) because of the extra scanning, we are almost certain to see large numbers of networks disappear from the dialog shortly after it is shown, which is a pretty bad user experience As such, NM plans to introduce a 'scan age' property that tells how long ago the network was last seen. gnome-shell should also probably try to use this when populating the dialog so that it avoids adding networks that were only seen a long time ago. Once the dialog is open, however, we should show anything picked up since it was opened.
Instead of gnome-shell poking NM to get scans, I'd to have some persistent property that raises the scan frequency. The advantage would be that NM would know that the user is interested in seeing more networks as opposed to keep the current channel/AP, and would avoid failing scans if another connection is active (see bug 732635 for an example, but there is a quite few conditions that cause NM to just return an error).
I agree with this, but Dan had some reservations. In particular, he was concerned that it might be difficult to track clients that crashed or made mistakes and forgot to turn off the "aggressive mode". I actually thought that it would be better a step further: an API on libnm that enters agressive mode and does the appropriate filtering that I mention above (ie: ignoring old stale results at first), returning and updating a list of access points suitable for showing to the user.
That's more a problem with NetworkManager's API being nigh impossible to use correctly rather than something we're doing.
(In reply to comment #2) > I agree with this, but Dan had some reservations. In particular, he was > concerned that it might be difficult to track clients that crashed or made > mistakes and forgot to turn off the "aggressive mode". Right. One possibility would be to timeout the aggressive mode automatically, and disable it after, say 60 seconds. Which IMHO makes sense for this use case, because if an AP is not visible after 60 seconds of high-power low-speed high-accuracy frequent scans, it's not there at all. It would somehow get in the way of people leaving the wifi dialog open while the move the laptop to a place that has wifi, but with a modal dialog it doesn't sound like an interesting use case.
*** Bug 748750 has been marked as a duplicate of this bug. ***
*** Bug 751195 has been marked as a duplicate of this bug. ***
*** Bug 757106 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 767918 ***