We have moved to a new Sailfish OS Forum. Please start new discussions there.
5

severe lags after updating to 2.1.3.7 (connman-related)

asked 2017-12-20 17:17:21 +0200

Ivan Sorokin gravatar image

updated 2017-12-26 04:14:46 +0200

Hello. I have just updated my phone (Jolla 1) to version 2.1.3.7. Perhaps I skipped a few versions. Since the update I experience severe lags (for ~1 second). During the lag the phone ignores touch actions, so I often have to redo some actions.

Here is the video: https://drive.google.com/file/d/1aKg1emnEzJzdJ0xa6dSo042i7bQIcbh5/view?usp=sharing

At the 4th second you can see that the phone ignored my swipe and at the 7th second you can see a lag for about 1 second. These lags happen while scrolling icons on the home screen, during application minimization/closing, during browsing network related settings.

These lags degrades user experience significantly (because touch actions during them are ignored).

update 1To provide a bit more information to diagnose the issue I did the following: I connected using ssh. Run top -d 0.2 and reproduced the lag. Here is the video: https://drive.google.com/file/d/15H-4euSO_F7S_OtwLqM65KZ7s2BYtGMy/view?usp=sharing as you can see during the lag the processes that eats CPU time are: lipstick (the process where we see the lag), dbus-daemon and connmand. One can only wonder what type of communications is going on between lipstick and connmand during the lag.

update 2 I did another test. I turned on flight mode and the lags disappeared. Turning off the flight mode enables lags.

update 3 I have never debugged dbus-related issues, but I tried using dbus-monitor (--session and --system) to see what messages are send during the lag. dbus-monitor --system shows nothing and dbus-monitor --session show only 2 messages:

signal time=1513789428.243024 sender=:1.19 -> destination=(null destination) serial=841 path=/com/jolla/lipstick; interface=com.jolla.lipstick; member=coverstatus
   int32 1
signal time=1513789428.243085 sender=:1.19 -> destination=(null destination) serial=842 path=/com/jolla/lipstick; interface=com.jolla.lipstick; member=coverstatus
   int32 2

update 4 I tend to think that connmand is the problem. Stopping it by using systemctl stop connman makes system very smooth. I think that perhaps lipstick does some blocking rpc calls to connmand. Profiling connmand show that most of the time is spent on doing dbus serialization/deserialization. Now I need to see somehow what is going on in dbus during the lags.

Tell me if I can provide more information.

edit retag flag offensive close delete

Comments

What is your device Jolla 1, Jolla c or aquafish?

Jk ( 2017-12-20 17:23:50 +0200 )edit

It's Jolla 1. Sorry I didn't mentioned that. I edited my post.

Ivan Sorokin ( 2017-12-20 17:27:45 +0200 )edit

severe lags everywhere in the operating system, its very much a work in progress.

DarkTuring ( 2017-12-21 04:06:37 +0200 )edit

Did you check your BTRFS volume?

Alex ( 2017-12-21 14:27:17 +0200 )edit

Did you check your BTRFS volume?

I didn't know it can slow down a system. Why can it slow down a system and how to check it?

Ivan Sorokin ( 2017-12-23 20:00:57 +0200 )edit

1 Answer

Sort by » oldest newest most voted
1

answered 2019-02-28 18:36:49 +0200

Self-Perfection gravatar image

updated 2019-03-30 23:17:41 +0200

I have the same issue with Jolla C for months! This frequently happens when I go away from Wi-Fi and device switches to mobile data. While UI lags connmand and dbus-daemon take lots of CPU time, like 20-30% by top output. Luckily we have SystemDataScope now, I used it to monitor this process:

connmand: CPU time dbus-daemon: CPU time

Notice how similar this graphs. At the time of spike I noticed severe lags. At one point I could not switch to another app because of lags! Device noticed tapping on desired app cover but could not process finger removal in time, then assumed it was long tap and switched to "closing apps mode" (when under each app cover there is cross to close it). Five attempts and every time Jolla thinks it was long tap instead of normal tap. Ugh!

UPD: I hoped that release 3.0.2 would fix this. According to its changelog:

Connectivity

  • Bluetooth scan around a lot of Bluetooth devices no longer slows down the whole device
  • WLAN network scan around a lot of WLAN hotspots no longer slows down the whole device

Alas! The issue still present after upgrade.

edit flag offensive delete publish link more
Login/Signup to Answer

Question tools

Follow
3 followers

Stats

Asked: 2017-12-20 17:17:21 +0200

Seen: 781 times

Last updated: Mar 30 '19