Ubuntu
network-manager package

Bug #1480877
Comment #62

Comment 62 for bug 1480877

Revision history for this message

Tony Espy (awe) wrote on 2015-11-06:

#62

@Michael

Thanks again for your help with testing this.

1) When the phone disconnects from an AP, the scan interval drops to it's lowest possible interval ( 20s ), as the goal is re-connecting as quick as possible. It'll eventually drift back to ~60s.

2) I also get the very brief <= 1s stutter when a WiFi scan occurs. I mention this in comment #57.

If you look at the output of the dbus get-all-match rules script on mako ( comment #55 ), there are many other processes that are attached to the system bus and have specified less-than-optimal DBus match rules. We should indeed try to work through each project.

That *said*, right now I think we should fix the obvious location-service issues which can cause the UI to lockup for close to 5-6s. That needs to be job one. I added a location-services task ( assigned to Scott on my team ) to track. That said, I don't propose we add tasks to this bug for every other project listed in the dbus match rule output... First, we should review with the product team if they're OK with closing out this bug once the location services fix(es) have landed.

As for when you see the problem, again it really depends on what the scan interval is. If you're connected to an AP, it's ~2m, so you might not notice the <=1s stutter when it happens. If the iterval is 15s ( ie. when location-services is in control of scanning ), it's *much* more noticeable.

My krillin right now is max'd out at 5k rules per loc daemon. The UI hangs for 4-5s each time a scan occurs, the frequency is per the above conditions... It's really bad when it gets to this point.

So, the fixes I think we need asap are:

- fix location-services scanning behavior ( when is it supposed to be turned on, and when is it shut off? seems broken atm )

- fix location-service match rules ( duplicate, and leaks; really only need one rule for all AccessPoint objects )

It also would be nice to understand why the same DBus traffic needs to be monitored by all three processes ( see comment #52 for more on this ).

@Michael

Thanks again for your help with testing this.

1) When the phone disconnects from an AP, the scan interval drops to it's lowest possible interval ( 20s ), as the goal is re-connecting as quick as possible.  It'll eventually drift back to ~60s.

2) I also get the very brief <= 1s stutter when a WiFi scan occurs.  I mention this in comment #57.

That *said*, right now I think we should fix the obvious location-service issues which can cause the UI to lockup for close to 5-6s.   That needs to be job one.  I added a location-services task ( assigned to Scott on my team ) to track.   That said, I don't propose we add tasks to this bug for every other project listed in the dbus match rule output...  First, we should review with the product team if they're OK with closing out this bug once the location services fix(es) have landed.

As for when you see the problem, again it really depends on what the scan interval is.  If you're connected to an AP, it's ~2m, so you might not notice the <=1s stutter when it happens.   If the iterval is 15s ( ie. when location-services is in control of scanning ), it's *much* more noticeable.

My krillin right now is max'd out at 5k rules per loc daemon.  The UI hangs for 4-5s each time a scan occurs, the frequency is per the above conditions...  It's really bad when it gets to this point.