#81 Battery consumption

[Anonymous]

Originally created by: egcros...@gmail.com
Originally owned by: r3gis...@gmail.com

Maybe this issue is too vague to register as a "defect" but as there is no discussion forum for CSipSimple, here goes:

I was using Sipdroid for a while, but I strongly dislike their UI decisions so I am trying alternative SIP agents. I actually talk very little, maybe a few minutes per day but I have SIP agent registered at all times when under WiFi coverage. When I run Sipdroid, by the end of the day I have battery indicator at about 50%. When I run CSipSimple instead, with all other activities basically the same, by the end of the day the battery indicator is yellow or even red (< 20% I think).

This issue and loosing registration (issue #67 comment #4) are two things that makes this program less acceptable to me than Sipdroid. Otherwise, I am happy with the UI and satisfied with stability.

HTC Desire, Android 2.1, CSipSimple pre5.

[Anonymous]

Originally posted by: nnsl...@gmail.com

@tobias, what network are you on? tmo, verizon, sprint? Who is the VOIP provider behind sipsorcery? Also, how is the call quality with sipsorcery?

@krolaw, I have an EVO on sprint, and the symptoms for me are the same on wifi (no sleep), and 3G (always available). The only way I can get calls consistently is to use partial wake lock.

I have a sipsorcery account, so I may try funneling my SIP traffic through them, and see what happens.

[Anonymous]

Originally posted by: nnsl...@gmail.com

Wow, it works great with SipSorcery. Thanks @tobias for (a) reminding me I have a SipSorcery account, and (b) the great idea to use it. Works great now!

[Anonymous]

Originally posted by: presslab...@gmail.com

I noticed that if my SIP server is down and the phone can't connect, battery comsumption goes through the roof.  Otherwise it seems fine to me.

[Anonymous]

Originally posted by: vphan...@gmail.com

Here's something interesting: I noticed that my airplane mode is a lot more power-hungry and I suspect cSipSimple, as it's the only new bit of software since this started happening.  Funny thing is, in the Market version, I have "use partial wakelock" unchecked, and Lock WiFi unchecked already.

One thing I'm experimenting with now: I disabled Incoming WiFi so that the client doesn't try to register outside of periods I manually launch it, until I later quit it.  (Works great, that's the setting I was looking for!)  Even if I use System Panel to kill it after I quit it, I notice it reappears in my process list shortly after (like the annoying Amazon MP3).  I would've expected it not to be restarted at all when configured that way.  Is this normal or am I missing an extra setting to disable that?

[Anonymous]

Originally posted by: r3gis...@gmail.com

Yes it's normal that it appear in application list. Most of users are afraid about apps that appear in application list.
But actually that's harmless :
Android manage its own memory by it's own way. As CSipSimple potentially listen for network changes event (even if it actually does nothing if your configuration is set too), android put things in RAM memory and the app does absolutely nothing in background.

Those "auto-kill apps" are a really useless thing for android 2.0 and upper.
And even worse sometimes if set to auto-kill these apps can drain the battery cause just try to umount things in memory and then android automatically restart the apps and it loop infinitely...

I'm not alone to say that great android gurus (the ones that code the android OS), try to explain this ... but unfortunately users still use this task manager apps in auto-kill mode.
You should for example read that :
http://blog.radioactiveyak.com/2010/05/when-to-include-exit-button-in-android.html
http://androidspin.com/2010/05/25/why-you-dont-need-a-task-killer-app-with-android/
http://android-developers.blogspot.com/2010/04/multitasking-android-way.html

And so on...

Besides I'd like to add that in development version there is a more user friendly way to quit the app.
However it doesn't mean that it will disappear from task list. Just that it will do nothing. But appearing in the task list doesn't mean that it consume resources... even better sometimes it means that the application will consume less resources when waked up back.
You can compare that to the "suspend/hibernate" mode of a PC. It just freeze everything in memory to be able to wake up things quickly. And here in our case, it's managed by the Android OS system. it's not up to the developer to deal with that.

[Anonymous]

Originally posted by: alekse...@gmail.com

I'm not a developer nor an expert so maybe i'm going to say a very stupid thing! :)
To save battery and also receive incoming calls can you use google's push tecnology (C2DM) introduced with froyo? I noticed that application that use it don't waste battery at all, but are able to provide notifications very quickly. Examples of them are google's gmail app, google calendar, Chrome to phone, WhatsApp (it works great!), K9 mail client (not sure but i think so), BeeJive IM, ...
It's just a suggestion based on what i've seen until now, i don't know if it is really possible

[Anonymous]

Originally posted by: egcros...@gmail.com

To comment 31:

1. To "notice" C2DM events the handset needs to be connected to Internet at all times, this is not substantially different from being registered directly with a SIP server. There is no magic here that could dramatically decrease the power consumption.

2. To "notice" incoming INVITEs, some sort of proxy will need to run somewhere "in the cloud", registered with the SIP provider, and producing C2DM notices when it receives an INVITE. This would make the system prohibitively complicated, compared to the device directly talking to the service provider as it normally does.

3. The delay of C2DM delivery is at times much longer than an average person is prepared to wait for her call to be answered.

[Anonymous]

Originally posted by: vphan...@gmail.com

A follow-up on my comment #29 above.  Now that I disabled Incoming WiFi, I can confirm that my Airplane Mode battery consumption is back to its normal 4-5%/day, so that seems to have been the cause for me.  (Nexus One, by the way.)  Luckily I prefer to manually activate my SIP client during periods when I make myself available, so I want Incoming WiFi to be off anyway. Problem solved for me. :)

Bottom line, whatever monitoring Incoming WiFi incurs, is consuming a bit of battery power during Airplane Mode; perhaps Airplane Mode itself could be detected to further reduce the amount of work cSipSimple does during that time?  Just a thought, I'm already quite happy with how things are now that I found this tweak.

[Anonymous]

Originally posted by: fander...@gmail.com

To r3gis.3R and egcrosser regarding PARTIAL_WAKE_LOCK usage:

My understanding is that receipt of a network packet over an active interface (e.g. non-sleeping wifi) while the phone is sleeping will generate a CPU interrupt which will wake the CPU for a fixed small period of time (fraction of a second).  If the processing triggered by the packet requires more time to complete, the application should obtain a partial wake lock when processing starts and release it when processing finishes.  This explains why pinging the phone works when it's sleeping, and also implies that SIP applications should be obtaining and releasing wake locks dynamically, not holding them forever.  I'd expect this change to result in much lower battery consumption without sacrificing incoming call reliability.

[Anonymous]

Originally posted by: egcros...@gmail.com

fanderay4, every I/O event generates an interrupt. The point is, when the CPU is switched off, it cannot process interrupts. However, when the network chip receives a unicast packet it generates a special signal (in addition to the interrupt) that switches the CPU on. Then the CPU handles the interrupt, and the kernel dispatches any application that might be waiting for this packet. The OS gives this application fixed time (10 seconds if I remember correctly) to run, and then switches the CPU off again. If the application decides that it needs to run longer to do its job, it must obtain any of WAKE_LOCKs before the 10 second interval expires. And this is how csipsimple works (unless you check the "Use partial wake lock" checkbox in the settings, in which case it will keep the lock all the time).

[Anonymous]

Originally posted by: fander...@gmail.com

Thanks for the clarification egcrosser.  If that's true then I don't see why the "Use partial wake lock" setting should ever be needed, and yet when I disable it, I permanently lose registration...

[Anonymous]

Originally posted by: egcros...@gmail.com

fanderay4, some combinations of hardware/OS version are known to have a bug: the radio chip it programmed improperly and does not wake up the CPU on incoming packets. I don't remember the number off the top of my head, you might try to look it up in android bugs section. If this is indeed your problem then you need to either upgrade the OS or "Use partial wake lock".

[Anonymous]

Originally posted by: fander...@gmail.com

I use wifi only (sleep policy set to Never) with an HTC Wildfire running CyanogenMod 6.1-RC.  The only problem I'm aware of is <https://code.google.com/p/cyanogenmod/issues/detail?id=2403> which I knew to be responsible for having to set the "Stay awake during call" workaround option.  I guess that's the culprit in this case too.

[Anonymous]

Originally posted by: r3gis...@gmail.com

+1 for egcrosser comment.

However there is still something that is still open and has to be explored :
Actually, for incoming packet CSipSimple works the way you explained (if there is an incoming INVITE, csipsimple took a wake lock (however could be done more lower in pjsip sip stack but would be not easy to maintain (and probably not needed at all).

On the other side, CSipSimple tries to keep the UDP (or TCP) connection alive. To do so, it send (actually pjsip sends) packets every 'keep-alive interval' time. This is done inside the native library and no wake lock is done on this part. So if your sip server is not talkative, and supposing CPU is turned off by the OS, nothing will wake up pjsip threads to send the keep alive. (-- but that's not clear, as the thread is not registered by the dalvik JVM, I'm not sure at all of that --).
This is needed only if your carrier routers (or IP provider) cuts a connection without any traffic.

A solution could be to use Alarms from android SDK ( http://developer.android.com/reference/android/app/AlarmManager.html ). But problem is to get that synchronized with the pjsip native stack on which we rely. In a first time could be an awful hack available as an option (intermediate to Lock CPU and no lock CPU).

This is a really tricky point to handle, all the more so as all devices doesn't manage things the same way, that all routers equipments doesn't behaves identically and that some sip servers are more talkative than others (some send frequent Notify which could be a solution). So to get something that works perfectly in all case and consume the optimal battery is really hard and should be thought as a background task (that I actually keep in mind but not top most priority for now) (reason why this issue is marked as task. If anybody wants to have a really close look to the issue and propose patches it will be welcome. ;).

[Anonymous]

Originally posted by: mcampbel...@gmail.com

Question: Which is better on battery life for the Android phone: A server that is talkative and sends keep alive packets every X seconds, or for the phone to send the keep alive packets every x seconds?

Or are they equal?  Thanks

[Anonymous]

Originally posted by: egcros...@gmail.com

r3gis,
regarding re-registration from inside pjsip, do you happen to know how they are woken up to do the job at particular time? If they use Android's alarm manager, maybe getting and releasing the lock could be done in the "outer" Java part of the event handler?

If they are using unix alarm(2), then theoretically, it should be pjsip's job to obtain the lock for the duration of the registration process. As pjsip code would not want to deal with Java interfaces directly, maybe they could be persuaded to invoke caller-supplied callbacks before and after re-registration. Then csipsimple could provide such callbacks, in which the lock will be obtained and released.

Or maybe my speculation is completely off the point. In that case, just disregard it.

Also, I must tell that for me, the app works very stable recently. "Unexplained" loss of registration happens sometimes, but very seldom. I would not even be able to test a possible solution because problem is so rare.

[Anonymous]

Originally posted by: r3gis...@gmail.com

@mark : it depends on implementation on the phone. For now csipsimple is most friendly with the talkative server approach (but server should send it with a not so high frequency to not drain the battery. However in the absolute the best approach is to let the client to be talkative : it may allow the client to detect it's own network type and adapt frequency of it's ka packets to the network type. On the other side, if we assume a alarm implementation, I'm not enough an expert to say whether alarm or waiting network socket is the best approach in term of battery usage.
What I can say is that if both server and client try to send keep alive packets one of the two are useless. (Most of the time in this case we'd like client to be silent). And also that if server send keep alive most of the time it's through a NOTIFY so it's a little bit heavier to process that a client packet (just a \r\n).

@egcrosser : Yes indeed could be integrated with pjsip. I've to check that but maybe could be done in the os_android.c port : it's the implementation some stuff for android regarding threading and scheduling, so could be managed safely and cleanly here, even if we need to talk to the java part. (That's already the case for the audio driver which is a separate source file).
So worth to explore this approach. But I'll have to really focus on that and only that when I'll do this work :) For now too much other side things to do ;).

[Anonymous]

Originally posted by: m...@mykohsu.com

I am also experiencing high battery drain with cSipSimple on a custom Androd on HTC HD2. This is probably unsupported but the drain is normal (5-10mA) without cSipSimple registered. I use Battery Monitor Widget to monitor the devices battery usage.

Currently I have cSipSimple configured with a PBXes account over TCP with keep-alive set at 100 and register interval set at 1800. As long as cSipSimple is registered, battery drain is in the ~150mA vicinity. This translates to about 12%/hour with the screen off and me not using the phone.

[Anonymous]

Originally posted by: m...@mykohsu.com

Update to comment 43: I disabled all incoming data for cSipSimple (WIFI, 3G, etc) and disconnected. After letting it settle down to 5mA draw for a few minutes, I re-enabled the incoming data from easy settings and so far it is still at 5mA draw. Going to keep monitoring this.

[Anonymous]

Originally posted by: r3gis...@gmail.com

@nlm : are you configured to be "always available" over wifi only?
If so be aware of the fact that in this mode CSipSimple try to ensure that wifi is running which drain the battery (but if you want to be always available and use only wifi for that, that's the only solution, no miracle can be done ;) ).

I think that if you go in android device infos (android settings > about phone > battery usage) and have a look to what is consuming battery, you'll not find csipsimple but wifi as first entry.

A good compromise is to choose "available on wifi" (which keep your wifi policy - I assume when screen is on). Or if you don't mind to receive calls, "only for outgoing".

You can also try latest trunk version in which I've a little bit improves things regarding cpu consumption, but I don't think that it will help a lot, 12%/hour is really really high (I never have that on my phone except on the galaxy S when there were a wifi bug on the ROM I used).

Usually on my phones when 1%/hour is without csipsimple always running and activated I get 3-4%/hour when activated and locking wifi.
However if the wifi driver of your phone doesn't behaves correctly (which happened once on a ROM on my GalaxyS) it can increase a lot when wifi is locked by the app.

Just FYI, pbxes.org doesn't actually support very well TCP : they do not respect SIP RFC, which break pjsip (the SIP stack on which csipsimple rely), so you should disable it if you don't want to see unpredicatable latency when hanging up.

[Anonymous]

Originally posted by: fander...@gmail.com

I have been observing another strange behaviour related to idle CPU usage that has a significant impact on battery as well as phone performance:

I'm using an HTC Wildfire (528MHz ARM11 CPU) running Android 2.2.1 (csipsimple [r502]), and my SIP provider requires re-registration every 60 seconds.  The "Use partial wake lock" and "Stay awake while on call" settings are required for me.  What I observe, by running "top" from a shell, is that when csipsimple is started from cold, its idle/background CPU usage is very low: <1%, except that about once a minute it rises to 5-7% for a couple of seconds, which I assume is due to re-registration processing.

However, after csipsimple has been running for a while (several hours) I find, again looking at top output, that the periodic CPU usage during the regular "spikes" starts to increase considerably.  csipsimple's usage itself may rise to 10-15% for a couple of seconds, but much more significantly, the system_server process becomes active at the same time and runs at 80-90% for as long as 10-15 seconds.

At first I didn't know what was triggering the system_server spikes and was prompted to troubleshoot because the phone had slowed to a crawl.  In doing so I found that killing csipsimple solved the problem, and also that restarting it solved the problem for some time, until hours later the excess system_server consumption would start coming back.

It would be interesting to hear from others what CPU usage patterns you see while csipsimple is registered but idle.  Also any insight as to what system_server could be doing that would cause it to start churning the CPU this way and how it could be related to csipsimple would be very helpful.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Here we are.
[r590] ship a big improvement (I hope so) in the way it manage keep alive.
It's now totally different approach from the previous one so that it ~should~ allow you to disable "Use partial wake lock" if you previously needed it.
It should also improve battery lifetime cause now :
* The keep awake management is integrated with android OS approach of keep alives.
* Keep alive is done synchronized for all accounts.

As consequence keep alive setting is not anymore related to account settings but to global settings. BTW, there is two keep alive settings. One for Wifi and one for mobile. By default I set wifi keep alive to 100s and mobile to 40s. Any feedback on these values is welcome :).

Now what is missing thing to have the lower battery consumption : activating STUN feature only when needed. This is planned in pjsip project for next release (in one or two week). So we can hope to have that soon :).
I've already decreased STUN timer from 20s to 90s which should leads to better perfs too. But I think that we will reach the best when pjsip will have the STUN feature only on calls establishment.

[Anonymous]

Originally posted by: fander...@gmail.com

Initial testing of [r590] confirms this is a major improvement!  I can now disable "Use partial wake lock" in the settings without losing registration, and battery consumption seems much lower.  Great work!  (I set keepalive to 50 sec as provider's re-registration interval is 60 sec anyway)

[One very strange thing: my first test call with [r590] brought the phone to a standstill immediately.  Investigating this I found calls were using G.729 even though I had not activated it!  This was causing csipsimple to peg the CPU.  After going into settings and activating/deactivating it, this quirk seems to be resolved...]

[Anonymous]

Originally posted by: r3gis...@gmail.com

Yes, as for codec problem, that's cause new version now differentiate codecs priorities (between wideband and narrowband).
However I have some piece of code that should reset codec priorities for working with that and that should not activate g729. But I've just noticed that it was done only if previous installed version were < 584. And I guess you were using 585 before.

I fix that, thanks for the info.

As for your provider re-registration interval you should ask them to allow higher re-registration interval. Cause for mobile that's worse to have re-registration to 60s. By default CSipSimple tries to ask with 300s (5min which is already very frequent and could be optimized I think).
All the more so as with new method, keep alive have not a deep impact on battery it's interesting to use it instead of re-registration.

[Anonymous]

Originally posted by: zveda2000@gmail.com

I notice a high battery usage after making a call. Even if I turn off data, disable my sip account, and put the phone to sleep (it shows that it's been asleep the whole night), after only 10 hours or so the battery is nearly drained.

Then if I shutdown and turn the phone on again, all is well and the battery can last for 7 days or so in sleep mode. Something about making a call must stay on even after it is finished..