desktop-packages team mailing list archive

[Tony Espy <1480877@xxxxxxxxxxxxxxxxxx>]

@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
).

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1480877

Title:
  Access points' "PropertiesChanged" dbus signals freeze UI on mobile
  devices

Status in Canonical System Image:
  Confirmed
Status in indicator-network package in Ubuntu:
  Incomplete
Status in network-manager package in Ubuntu:
  Incomplete
Status in location-service package in Ubuntu RTM:
  New
Status in network-manager package in Ubuntu RTM:
  Incomplete

Bug description:
  Krillin, rc-proposed, r83

  
  DESCRIPTION:
  I've been trying to track down the cause of the occasional UI freezes on my Krillin device, and I noticed that whenever the UI freezes for 2-4 seconds, I get a burst of "PropertiesChanged" signals in dbus-monitor

  Here's a log of what's shown in dbus-monitor:
  http://pastebin.ubuntu.com/11992322/

  I'd guess the problem is in the code that actually catches the signals
  and acts accordingly.

  HOW TO REPRODUCE: 
  1) Move to a place where many wifi hotspots are available
  2) Connect the device via USB and run "phablet-shell" and then "dbus-monitor"
  3) Use the device while keeping an eye on dbus-monitor output

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1480877/+subscriptions