Battery Drain

[nurps]

Kept the webclient active a whole day, at the end of it the device was kept awake over 8h. That makes Threema with 22% the most energy hungry app at the moment on my phone.

Compared to the 0.5% that Threema uses without webclient or Whatsapp uses (WITH active webclient).

[Kurisutian]

Same Problem here with chromium (v 56.x) on Linux. For me Threema uses more than 40% battery through the day on my Xperia XZ and I can quite often see a notification on my phone indicating that the connection will be re-established. I'm pretty sure other users using phones with less battery capacity won't make it through the day, so this is some serious issue here.

[ovalseven8]

Same issue for me: Threema needs way too much energy (Android 6, Firefox). Would be great if this could be optimized a little.

Another person also wrote here: https://twitter.com/DaMoisture/status/832332294241341440

[simmac]

I experimented a little bit now, and I've found Opera to be the browser which works most efficiently with the Webclient. Google Chrome seems to be the most aggressive one (also on the Webclient side, the thread for the Webclient tab uses 15-30% CPU on my 2016 15" MBP), while the UI in Firefox is slow and laggy in compairison. Opera, the browser I usually don't use at all, is more efficient, this also shows on the Webclient side where the ThreemaWeb tab is stable at 9-10% CPU usage).

[lgrahl]

While this may be true, I wouldn't know why as Opera is Chromium-based and I'm fairly sure they haven't changed anything in the WebRTC related code. Could it be that your Chrome is outdated?

[simmac]

I'm using Chrome 56 (stable) and the newest Opera build (I only installed it yesterday for these tests).

Both running on the same machine: MacBook Pro 2016 15", macOS 10.12.

My test weren't very thorough though, I just opened the Webclient in a new browser instance and ran it for a minute or two while recording the CPU usage.

[ovalseven8]

Probably we should rename the issue to "Reduce battery drain" because there's already a separate issue for the high CPU.

[nurps]

That other issue is for the CPU on the PC running the browser client, this is about CPU usage on the source Android device..

[ovalseven8]

That other issue is for the CPU on the PC running the browser client, this is about CPU usage on the source Android device..

I see. Created #63 then.

[dbrgn]

The Webclient on Android must acquire a wakelock that prevents the phone from going to deep sleep. This is inevitable, since otherwise the connection would be killed by the system as soon as the screen is locked for a while (Android is quite strict about this).

It should only happen while a Threema Web connection is active though. And we might still be able to do some battery saving optimizations.

[nurps]

What about a different model where it only establishes the connection when a message is incoming or I start typing one?

[lgrahl]

@nurps The whole process to re-establish a connection between app and browser is really complex and time-consuming (in comparison to other Web Client solutions that require an app but do not use P2P). Not saying it's impossible but it will take a lot of fine tuning and little tweaks to find an algorithm that most people are pleased with.

[ovalseven8]

Another report with a screenshot just for information: https://twitter.com/cputzke/status/833725905856032768

[nurps]

Ok, well so far I just do that manually, establish the connection when I hear my phone has a message or if I want to contact someone.

To make this a little easier it would be convenient to reach the "closes session" button directly without going through a menu first.

And maybe have the option to reconnect without having to enter a password every time. This is my PC, no one else is going to use it, I personally would like to disable the password to be able to quickly activate and deactivate the webclient.

[lgrahl]

@nurps You should probably open another issue for this matter (Start/Stop Session Button or something like that).

[rugk]

As for the password: You can just generate one and save it in your browser. Then it will be auto-filled.

[matzex]

Do you have any updates on this issue? For me Threema web is not usable with this problem. Threema empties the battery within half a day if I use the web interface.

[dbrgn]

Next app version should improve battery life in some cases.

[dbrgn]

Threema for Android 3.1 was just released. It contains some fixes that should improve battery life in some cases (there was a bug in the wakelock handling).

The remaining battery usage is the result of the inevitable Android wakelock and there's probably not much more we can optimize. In case you have suggestions on how to improve battery usage for WebRTC + Android, we're open for feedback.

[ovalseven8]

@dbrgn: Did you a test at Threema concerning the battery drain with Threema 3.1 compared to Threema 3.0? How much difference is there?

[dbrgn]

@ovalseven8 the bug affected the case where a wakelock was still active even when Threema Web was disconnected. So if you only use Threema Web from time to time the difference will be big, if you use it all day long there won't be a big difference.

[ovalseven8]

I wonder if we should reopen the issue because it feels like battery drain increased again. Is there being worked on?

[dbrgn]

I wonder if we should reopen the issue because it feels like battery drain increased again. Is there being worked on?

In case you are using the beta, yes it is. It's beta for a reason :)

[ovalseven8]

Okay, nice to hear that Threema is working on that important issue. :smiley:

[ovalseven8]

For your information (latest beta): It seems like the battery drain is higher when I use different sessions (not at the same time!). Perhaps sessions are not properly closed or, well, no idea.

[ovalseven8]

@dbrgn @lgrahl @sillych

The release note for the latest beta (3.19.2000369) says that the battery drain was reduced. So I tested it today. At 11:45 I've started (full battery) and at 20:15 I've closed the session. I am not fully satisfied about the results but I guess there are definitely some improvements.

I did not really use my smartphone for that time (it just laid at the table). Also Threema Web was about 98 % of the time in the background. However, I could find an interesting thing when I looked at the battery page in Android just now, what confirms my subjective feeling: There was a period with an higher battery drain compared to at the beginning and at the end. You can see in the image below the period when the battery dropped much faster.

I remember that I've closed the session ~in the middle of my test and used another session immediately then. My feeling says that with the new session the battery drain was better again. Maybe I've changed the session once again during the test, don't know anymore. But I definitely remember that I've changed the session at least one time.

To sum it up: I think that Threema used too much battery for that time, but if there would not have been this increase in battery drain for that period then the battery drain would be "acceptable" at least. If I probably would not have changed the session, then the battery drain would have been dramatically high.

Below you can also find the log for my test. I hope it helps and you can fix this potential bug.

message_log.txt

[ovalseven8]

What's perhaps interesting for you: Your logs seem to be ~wrong. Here a simple test.

21:21: Connect with Threema Web 21:23: Disconnect

Here the log since 21:21:

Fri Sep 08 21:21:00 GMT+02:00 2017  releaseConnectionLinger: source = activityPaused, timeout = 60000
Fri Sep 08 21:21:00 GMT+02:00 2017  Cancel Alarm 1
Fri Sep 08 21:21:00 GMT+02:00 2017  Schedule alarm 1 in 59998ms
Fri Sep 08 21:21:00 GMT+02:00 2017  releaseConnection: source = activityPaused, refCount = 0
Fri Sep 08 21:21:00 GMT+02:00 2017  cleanupConnection: connection must linger for another 59994 milliseconds
Fri Sep 08 21:21:00 GMT+02:00 2017  acquireConnection: source = activityResumed, refCount = 1
Fri Sep 08 21:21:00 GMT+02:00 2017  connection already active
Fri Sep 08 21:21:00 GMT+02:00 2017  releaseConnectionLinger: source = activityPaused, timeout = 60000
Fri Sep 08 21:21:00 GMT+02:00 2017  Cancel Alarm 1
Fri Sep 08 21:21:00 GMT+02:00 2017  Schedule alarm 1 in 59998ms
Fri Sep 08 21:21:00 GMT+02:00 2017  releaseConnection: source = activityPaused, refCount = 0
Fri Sep 08 21:21:00 GMT+02:00 2017  cleanupConnection: connection must linger for another 59996 milliseconds
Fri Sep 08 21:21:00 GMT+02:00 2017  acquireConnection: source = activityResumed, refCount = 1
Fri Sep 08 21:21:00 GMT+02:00 2017  connection already active
Fri Sep 08 21:21:07 GMT+02:00 2017  releaseConnectionLinger: source = activityPaused, timeout = 60000
Fri Sep 08 21:21:07 GMT+02:00 2017  Cancel Alarm 1
Fri Sep 08 21:21:07 GMT+02:00 2017  Schedule alarm 1 in 59998ms
Fri Sep 08 21:21:07 GMT+02:00 2017  releaseConnection: source = activityPaused, refCount = 0
Fri Sep 08 21:21:07 GMT+02:00 2017  cleanupConnection: connection must linger for another 59995 milliseconds
Fri Sep 08 21:21:07 GMT+02:00 2017  *** App UI is hidden
Fri Sep 08 21:21:07 GMT+02:00 2017  onTrimMemory: 20
Fri Sep 08 21:21:09 GMT+02:00 2017  SessionInstanceService[5]: Starting Threema Web session
Fri Sep 08 21:21:09 GMT+02:00 2017  acquireConnection: source = activityResumed, refCount = 1
Fri Sep 08 21:21:09 GMT+02:00 2017  connection already active
Fri Sep 08 21:21:15 GMT+02:00 2017  releaseConnectionLinger: source = activityPaused, timeout = 60000
Fri Sep 08 21:21:15 GMT+02:00 2017  Cancel Alarm 1
Fri Sep 08 21:21:15 GMT+02:00 2017  Schedule alarm 1 in 59994ms
Fri Sep 08 21:21:15 GMT+02:00 2017  releaseConnection: source = activityPaused, refCount = 0
Fri Sep 08 21:21:15 GMT+02:00 2017  cleanupConnection: connection must linger for another 59987 milliseconds
Fri Sep 08 21:21:15 GMT+02:00 2017  *** App UI is hidden
Fri Sep 08 21:21:15 GMT+02:00 2017  onTrimMemory: 20
Fri Sep 08 21:21:16 GMT+02:00 2017  PassphraseService: *** PassphraseService task removed
Fri Sep 08 21:22:15 GMT+02:00 2017  *** App UI is hidden
Fri Sep 08 21:22:15 GMT+02:00 2017  onTrimMemory: 20
Fri Sep 08 21:22:15 GMT+02:00 2017  AlarmManagerBroadcastReceiver: onReceive
Fri Sep 08 21:22:15 GMT+02:00 2017  Alarm (1)
Fri Sep 08 21:22:15 GMT+02:00 2017  stopConnection
Fri Sep 08 21:22:15 GMT+02:00 2017  ThreemaConnection state changed: DISCONNECTED Port: 5222 IPv6: false
Fri Sep 08 21:22:15 GMT+02:00 2017  cleanupConnection: connection closed

Yep, basically nothing. Note that 21:23 is past already but there is no log for this time.

Now I open the Threema app again. Here the log now: Very strange.

Fri Sep 08 21:21:00 GMT+02:00 2017  releaseConnectionLinger: source = activityPaused, timeout = 60000
Fri Sep 08 21:21:00 GMT+02:00 2017  Cancel Alarm 1
Fri Sep 08 21:21:00 GMT+02:00 2017  Schedule alarm 1 in 59998ms
Fri Sep 08 21:21:00 GMT+02:00 2017  releaseConnection: source = activityPaused, refCount = 0
Fri Sep 08 21:21:00 GMT+02:00 2017  cleanupConnection: connection must linger for another 59994 milliseconds
Fri Sep 08 21:21:00 GMT+02:00 2017  acquireConnection: source = activityResumed, refCount = 1
Fri Sep 08 21:21:00 GMT+02:00 2017  connection already active
Fri Sep 08 21:21:00 GMT+02:00 2017  releaseConnectionLinger: source = activityPaused, timeout = 60000
Fri Sep 08 21:21:00 GMT+02:00 2017  Cancel Alarm 1
Fri Sep 08 21:21:00 GMT+02:00 2017  Schedule alarm 1 in 59998ms
Fri Sep 08 21:21:00 GMT+02:00 2017  releaseConnection: source = activityPaused, refCount = 0
Fri Sep 08 21:21:00 GMT+02:00 2017  cleanupConnection: connection must linger for another 59996 milliseconds
Fri Sep 08 21:21:00 GMT+02:00 2017  acquireConnection: source = activityResumed, refCount = 1
Fri Sep 08 21:21:00 GMT+02:00 2017  connection already active
Fri Sep 08 21:21:07 GMT+02:00 2017  releaseConnectionLinger: source = activityPaused, timeout = 60000
Fri Sep 08 21:21:07 GMT+02:00 2017  Cancel Alarm 1
Fri Sep 08 21:21:07 GMT+02:00 2017  Schedule alarm 1 in 59998ms
Fri Sep 08 21:21:07 GMT+02:00 2017  releaseConnection: source = activityPaused, refCount = 0
Fri Sep 08 21:21:07 GMT+02:00 2017  cleanupConnection: connection must linger for another 59995 milliseconds
Fri Sep 08 21:21:07 GMT+02:00 2017  *** App UI is hidden
Fri Sep 08 21:21:07 GMT+02:00 2017  onTrimMemory: 20
Fri Sep 08 21:21:09 GMT+02:00 2017  SessionInstanceService[5]: Starting Threema Web session
Fri Sep 08 21:21:09 GMT+02:00 2017  acquireConnection: source = activityResumed, refCount = 1
Fri Sep 08 21:21:09 GMT+02:00 2017  connection already active
Fri Sep 08 21:21:15 GMT+02:00 2017  releaseConnectionLinger: source = activityPaused, timeout = 60000
Fri Sep 08 21:21:15 GMT+02:00 2017  Cancel Alarm 1
Fri Sep 08 21:21:15 GMT+02:00 2017  Schedule alarm 1 in 59994ms
Fri Sep 08 21:21:15 GMT+02:00 2017  releaseConnection: source = activityPaused, refCount = 0
Fri Sep 08 21:21:15 GMT+02:00 2017  cleanupConnection: connection must linger for another 59987 milliseconds
Fri Sep 08 21:21:15 GMT+02:00 2017  *** App UI is hidden
Fri Sep 08 21:21:15 GMT+02:00 2017  onTrimMemory: 20
Fri Sep 08 21:21:16 GMT+02:00 2017  PassphraseService: *** PassphraseService task removed
Fri Sep 08 21:22:15 GMT+02:00 2017  *** App UI is hidden
Fri Sep 08 21:22:15 GMT+02:00 2017  onTrimMemory: 20
Fri Sep 08 21:22:15 GMT+02:00 2017  AlarmManagerBroadcastReceiver: onReceive
Fri Sep 08 21:22:15 GMT+02:00 2017  Alarm (1)
Fri Sep 08 21:22:15 GMT+02:00 2017  stopConnection
Fri Sep 08 21:22:15 GMT+02:00 2017  ThreemaConnection state changed: DISCONNECTED Port: 5222 IPv6: false
Fri Sep 08 21:22:15 GMT+02:00 2017  cleanupConnection: connection closed
Fri Sep 08 21:26:16 GMT+02:00 2017  acquireConnection: source = activityResumed, refCount = 1
Fri Sep 08 21:26:16 GMT+02:00 2017  startConnection
Fri Sep 08 21:26:16 GMT+02:00 2017  ThreemaConnection state changed: CONNECTING Port: 5222 IPv6: false
Fri Sep 08 21:26:16 GMT+02:00 2017  ThreemaConnection state changed: CONNECTED Port: 5222 IPv6: false
Fri Sep 08 21:26:16 GMT+02:00 2017  ThreemaConnection state changed: LOGGEDIN Port: 5222 IPv6: false
Fri Sep 08 21:26:17 GMT+02:00 2017  releaseConnectionLinger: source = activityPaused, timeout = 60000
Fri Sep 08 21:26:17 GMT+02:00 2017  Cancel Alarm 1
Fri Sep 08 21:26:17 GMT+02:00 2017  Schedule alarm 1 in 59998ms
Fri Sep 08 21:26:17 GMT+02:00 2017  releaseConnection: source = activityPaused, refCount = 0
Fri Sep 08 21:26:17 GMT+02:00 2017  cleanupConnection: connection must linger for another 59995 milliseconds
Fri Sep 08 21:26:17 GMT+02:00 2017  acquireConnection: source = activityResumed, refCount = 1
Fri Sep 08 21:26:17 GMT+02:00 2017  connection already active
Fri Sep 08 21:26:18 GMT+02:00 2017  releaseConnectionLinger: source = activityPaused, timeout = 60000
Fri Sep 08 21:26:18 GMT+02:00 2017  Cancel Alarm 1
Fri Sep 08 21:26:18 GMT+02:00 2017  Schedule alarm 1 in 59998ms
Fri Sep 08 21:26:18 GMT+02:00 2017  releaseConnection: source = activityPaused, refCount = 0
Fri Sep 08 21:26:18 GMT+02:00 2017  cleanupConnection: connection must linger for another 59996 milliseconds
Fri Sep 08 21:26:18 GMT+02:00 2017  acquireConnection: source = activityResumed, refCount = 1
Fri Sep 08 21:26:18 GMT+02:00 2017  connection already active
Fri Sep 08 21:26:20 GMT+02:00 2017  releaseConnectionLinger: source = activityPaused, timeout = 60000
Fri Sep 08 21:26:20 GMT+02:00 2017  Cancel Alarm 1
Fri Sep 08 21:26:20 GMT+02:00 2017  Schedule alarm 1 in 59993ms
Fri Sep 08 21:26:20 GMT+02:00 2017  releaseConnection: source = activityPaused, refCount = 0
Fri Sep 08 21:26:20 GMT+02:00 2017  cleanupConnection: connection must linger for another 59980 milliseconds
Fri Sep 08 21:26:20 GMT+02:00 2017  *** App UI is hidden
Fri Sep 08 21:26:20 GMT+02:00 2017  onTrimMemory: 20
Fri Sep 08 21:26:21 GMT+02:00 2017  PassphraseService: *** PassphraseService task removed

[dbrgn]

Your logs seem to be ~wrong.

Hm, what's wrong about the logs?

[dbrgn]

There was a period with an higher battery drain compared to at the beginning and at the end.

Unfortunately we won't know whether that is related to Threema or to another app, since the stats include all apps running on the phone. There can be fluctuations, but as long as you're not actively sending data through the connection that should only vary with the connectivity (when connectivity gets worse or if there are any changes then the WebRTC processes have to process more information).

[ovalseven8]

Hm, what's wrong about the logs?

No information about new connection, wrong timestamps, etc. For example I could not find any information about the connection to the session at 21:21. Or nothing about the disconnect at 21:23 etc.

Unfortunately we won't know whether that is related to Threema or to another app, since the stats include all apps running on the phone. There can be fluctuations, but as long as you're not actively sending data through the connection that should only vary with the connectivity (when connectivity gets worse or if there are any changes then the WebRTC processes have to process more information).

Well, what I can say is that Android did not install any updates etc. and there is no other app in the Android battery page (in addition to the image above the only thing you can add is "Android-System" with 1 %). Moreover, I did not use any app in this time. The WIFI connection was stable too normally. I don't know if it has something to do with the Threema app or WebRTC internals, but there is definitely something to optimize. Why that dramatically increased battery drain then?

I know that I downloaded a ~20 MB video from Threema Web, but don't know anymore when and even if I did: After the download the battery drain should be normalized. The download took not that long (<= 15 seconds). It's probably something hard to debug, but worth it because battery is the most critical resource for a smartphone.

[lgrahl]

@dbrgn It could be that continuous gathering is draining significantly more battery. As you know, on my phone both WiFi and mobile network candidates are being gathered, so there are definitely more sockets. I suggest a 12h test period with an idle web client - with and without continuous gathering. (Maybe this should even be part of your pre-release tests.)

[dbrgn]

The Webclient information is missing there, that's true. We should probably add some for debugging purpose before the final release. There's nothing wrong about the logs though. The entries about connectivity all relate to the connection with the Threema messaging server.

It's probably something hard to debug

Yes unfortunately :( I also kind of lost trust in the battery stats when I did some heavy debugging in the app (which probably used quite a lot of battery) but Threema didn't even show up in the battery stats. I could imagine that some native code background processes are not properly captured. I'm not very familiar with how these stats are gathered though.

It could be that continuous gathering is draining significantly more battery.

That could be true. On the other hand it may reduce reconnects in bad networks, which would also eat up battery quickly.

[lgrahl]

That could be true. On the other hand it may reduce reconnects in bad networks, which would also eat up battery quickly.

Mhh, maybe add an option in Troubleshooting? I mean, it's a cheap boolean switch. :wink: But before that I'd suggest doing the test first and see if it makes any difference.

[ovalseven8]

The Webclient information is missing there, that's true. We should probably add some for debugging purpose before the final release. There's nothing wrong about the logs though. The entries about connectivity all relate to the connection with the Threema messaging server.

Oh, okay. Didn't know that, sorry. :wink:

Nonetheless, I am pretty sure the increased battery drain has something to do with Threema/WebRTC. It has also been my subjective feeling that after using another session the battery drain normalized again. If I only knew the reason/exact time when the battery drain increased, then debugging would be easier at least. :/

[lgrahl]

Is there a way to retrieve statistics in libwebrtc regarding allocated sockets, amount of sent and received packets on layer ICE (STUN, TURN), DTLS, SCTP over time? This would at least help to isolate the problem on the network layer. Because it takes two to tango in networking (and we know that Firefox sent less connectivity packets in the past).

[dbrgn]

Is there a way to retrieve statistics in libwebrtc regarding allocated sockets, amount of sent and received packets on layer ICE

Maybe this helps a bit, but it probably won't give us any internal information re open sockets or stuff like that.

[ovalseven8]

Well, Threema should probably hire a QA/test engineer for those things. He'll have enough time to deal with it. :stuck_out_tongue:

I mean, as said above, battery is the most valuable resource. :confused: I'd reopen the issue.

[ovalseven8]

Mh, I wonder if WebRTC is the right protocol to use for keeping a connection up in the background. I am probably the wrong person to make a legit statement here, what do you mean @lgrahl?

What I understand is that WebRTC is really good if you want real-time communication as the name says. Using WebRTC to keep the connection between smartphone and browser seems to be very inefficient?

[lgrahl]

Let me say first that my focus when creating the web client prototype was to create something that is as secure as possible. Battery usage was decent when testing and it's still decent enough. My personal experience is that I can leave the web client open for 8 hours and battery usage increases by 100%. That's something I can live with... for now.

Regarding WebRTC in general: Bare in mind that WebRTC uses ICE which preferably uses UDP and that requires somewhat frequent keep-alive messages. Frequent enough to keep a port open in a potential NAT. In the past, some browsers have gone overboard with that (I've seen messages every 20ms). This is what I meant when I said: It takes two to tango. You can't do anything about that on the app side. And this is just one example. But I wouldn't say that this cannot be improved. Yes, the WebRTC that most people see is focussing on providing real-time communication, mostly audio/video. But that does not mean we cannot improve it to be battery-friendly. And there will be others who face the same problem. If this is something that severely affects the web client or some of my own projects, then I will take action and propose spec improvements (and others will likely do the same), make and propose changes to Firefox code, etc. But before that, there are a lot more low hanging fruits in the current implementation of the web client.

The web client could be improved for better battery usage:

1. The connection between app and web client can be temporarily severed if it's not being needed (no new messages, the tab is inactive, ...).
2. Replacing TURN with SaltyRTC application data.
3. Reducing the amount of RTTs needed for connection establishment (requires SaltyRTC spec work) and early data transmission over SaltyRTC. This would interact nicely with 1.

TL;DR: There's much room for improvement regarding battery usage before we need to take a closer look at WebRTC (and improve it - not replace it).

[ovalseven8]

Thank you for your explanations! :+1:

My personal experience is that I can leave the web client open for 8 hours and battery usage increases by 100%. That's something I can live with... for now.

Well, I mean that is very subjective. For me, 100 % is a lot and the image above shows that in this problematic period the battery usage increased probably by 200+ %.

All the modern operating systems like iOS and Android has been optimized for battery drain. Also the Threema app (without using Threema Web) seems to be quite fine. To throw over all those efforts just because you're using Threema web for some hours is a little bit comical.

It's good to hear that there is enough space for improvements and I really hope Threema will deploy those. Battery efficiency shouldn't be something with low priority.

[ftobin]

I would have loved to leave a threema web client tab open and use it like I do Google Voice, but given that the CPU drain is so immense (projected 8 hours instead of 2 days+ of CPU) I won't be able to do this :-(

[lgrahl]

@ftobin Are you talking about CPU drain on the device that's running the web client? If yes, that's another issue. In this issue we're discussing battery drain on the Android device.

[ftobin]

@lgrahl I was referring to the CPU drain on my phone as a result of having a Threema web tab open on my desktop.

[yeahnope]

Is there any update on this issue? It seems like threema web is causing the app to constantly use 100% on one core from time to time.

(Tested on Android 7.1.2 and with the web client running on firefox 57.0.4 (64-Bit))

[lgrahl]

@yeahnope Can you (somewhat) reproduce this in any way? What would be interesting as well is whether you've had a Threema voice call in between (background: it might be that initialisation of the lib for calls triggers some special behaviour).

[yeahnope]

I did not make any voice calls. I am not so sure anymore wether or not restarting the web page fixes the issue, as I've just realised that every connect/reconnect seems to be followed by 30-60 seconds of 100% cpu usage. So even though I haven't been able to reproduce the issue as of yet, it seems possible that the high cpu usage is caused by not fully stable connections? Is the high cpu usage after connecting intended/normal?

[lgrahl]

Really hard to say because that would require a very detailed look at Google's WebRTC code. It is to be expected that there is an initial phase where many packets will be sent (which might increase CPU load) for some time until one ICE candidate pair has been chosen. It might be that this phase repeats once an ICE candidate pair is deemed unstable and thus an unstable connection would increase CPU load. And I've also seen browsers behaving weird (e.g. sending STUN binding requests in a 20ms interval) which could also drain battery. However, considering the very high CPU load you've seen, I'd expect this to be a bug on a higher level, either in Google's WebRTC implementation or in the Threema app.

Edit: CPU usage after connecting shouldn't be that high, no.

[ovalseven8]

There is an issue for the CPU usage: https://github.com/threema-ch/threema-web/issues/39

This is about battery drain on the smartphone.

[lgrahl]

@ovalseven8 If you look at the applications running in the picture, you can see that this is htop output from the smartphone.

[ovalseven8]

@lgrahl Oh, right. Sorry, my fault. :smile:

Important issue, thanks @yeahnope for the report.

[yeahnope]

@lgrahl Since it's hard to replicate the seemingly random high-cpu usage from time to time, I tried to check some things about the 30-60seconds of high cpu-usage when connecting. I don't know how any of the RTC/ICE stuff works, but the js-console reports the following way before the high cpu usage ends: [PeerConnectionHelper] ICE gathering state change: complete [PeerConnectionHelper] No more local ICE candidates

Also I don't see more STUN packets wireshark during the high cpu phase than after it stops. I also tried using chrome instead of firefox and turning of ipv6 on the phone, both did not solve the issue (edit: wrote the wrong thing :/ ).