#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: r3gis...@gmail.com

You're right, for now absolutely no optimization has be done to reduce battery consumption. (The app is still in alpha phase).

But there is things you can already modify in settings that will reduce battery usage:

* In the account settings (using expert wizard), change the keep alive interval to 40 for example instead of 15. This is the default value in 0.00-12, so if you are using 0.00-12 nothing has to be done on this point. It will reduce by 3 the amount of packets sent to the sip server.
* In global settings > network settings, you can disable the Lock Wifi option. This option ensure wifi is always on, if you want to be sure to receive your calls. This option is probably turned off by default in SipDroid for example. Activating this option drain the battery but ensure you will receive all your calls if you are not authorized to use your 3G connection to receive/make calls.
* If you don't matter receiving your SIP calls and want to use it only for outgoing calls, CSipSimple provide a good option for that. In global settings > network settings, you can uncheck both wifi and 3G for incoming calls.
In this case, CSipSimple will launch itself ONLY when you want to place a call and you will save a lot of battery (highly better than sipdroid that frequently try to register or check if no registration is possible).

I've in my mind some improvements that will allow to save a lot of battery.

For issue #67 comment 2, 3 and 4, it's probably a display issue, I will work on it soon.

Labels: -Type-Defect Type-Task
Owner: r3gis.3R
Status: Accepted

[Anonymous]

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

For me personally, it is important to have it registered at all times (under WiFi). I have "register when on WiFi", and "outgoing/incoming calls when on WiFi", and I do _not_ have "Lock WiFi". The latter does _not_ impede incoming calls, and in fact I think I am not seeing diverted incoming calls since 0.12.

I have a feeling that battery use became a little better in 0.12 but it's within the margin of error, and may be just false impression.

I'll comment on #67 there.

[Anonymous]

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

I (idly) wonder if it would be possible to get away *without* holding PARTIAL_WAKE_LOCK. For re-registrations, be waken up by timed events, for answering calls, rely on being woken up by incoming unicast packet. I am not sure if the latter needs any special setup to work.

[Anonymous]

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

I don't think so.
For re-registration, it's possible yes. You can use timed events (known as "alarm" events in android -- see http://developer.android.com/intl/fr/reference/android/app/AlarmManager.html). Theses events are raised even if the phone is in the deep sleep mode (CPU off).

*But* for answering calls I think it is not possible :
In fact when CPU is in deep sleep mode, application can't treat network packets :
The CPU scheduler never give the token to android applications in this mode.
Some application (especially IM ones) pool (using alarms) to be sure there is no new message to treat, but this method doesn't match what we want with a telephony application. (Can be tested but not sure will be really good).

I know that iphone has such a feature with their new "multitask" os... (Note the quotes ;) ). I mean, the API enable to declare "multitask" sockets and when there is activities on theses sockets, there is a wake up of the system. Btw, that's really complicated to implement (all the more so as you try to use a cross plateform sip stack). Maybe one day such a feature will be allowed in the android sdk.

[Anonymous]

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

Interesting. I did this experiment: I stopped cSipSimple, (and anything that might use PARTIAL_WAKE_LOCK), verified that mPartialCount=0, unplugged it from USB, ran ping against it and turned it off by power button. By all reasons, the CPU must have been turned off. However, it continued to respond to ping (although with bigger delay due to PSP mode). This means that CPU did run "enough" to respond to ICMP echo requests. It is the kernel IP stack that sends echo reply packets, CPU must run to have them sent. This apparently supports my theory that when a packet is received by the WiFi adapter it wakes up the CPU.

What I did not check in this test is whether userspace processes will be dispatched, but from what I did observe, it seems worth a try to check if the app will work without constantly holding PARTIAL_WAKE_LOCK, does it?

I would try it myself but I have trouble building the package from source ("[exec] /export/src/csipsimple/CSipSimple/AndroidManifest.xml:2: error: No resource identifier found for attribute 'installLocation' in package 'android'" when I try "ant debug")

[Anonymous]

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

OK, I was able to check my theory. I commented out the lines that create and acquire PARTIAL_WAKE_LOCK (in SipService.java around the line 780), rebuilt the package, ran it, verified that mPartialCount was still zero while the app was running, unplugged USB, turned it off via power button, and made a call to the device.

And it worked!

Now, *maybe* it's still a good idea to get the lock for the duration of re-registration process, but for the rest of the time, it seems unneeded. And by not holding it all the time we maybe can save some battery juice. Do you think you should try?

[Anonymous]

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

just want to share that I made the same experience as egcrosser, battery life seems to be greater on sipdroid. I know it's alpha and am looking forward for changes.

bear in mind that sipdroid claims battery life is improved when using a PBX service like sipdroid's own PBXES.org. Now I don't know, but I use two sip accounts (one incoming, one outgoing) which are handled by PBX. With CsipSimple I just added both accounts. this could decrease battery life...

(sure, I could use PBX with CsipSimple... just fruit for thought)

[Anonymous]

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

Well the case for using pbxes to save battery life is to use a TCP connection to pbxes with a high keep-alive time since most NATs keep TCP connections open for a lot longer then UDP connections. This means the radio does not need to transmit data as often and thus saving battery life.

So if you have a provider or a server that supports TCP then you can use this directly with CSipSimple if not then unfortunately pbxes does not seem to work using TCP with the pjsip stack (or at least I have not gotten the combination to work as expected - see comments in bug 50). There are other options such as sipsorcery which work though.

But the PARTIAL_WAKE_LOCK is very interesting as this in connection with TCP might lead to improvements. Personally I think battery life is one of the most important issues that still needs to be solved.

[Anonymous]

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

Yes really interesting test egcrosser !

Really worth to be tried. At least in a first time as an option.
Since, we are still in the alpha phase it's probably worth to test to disable the partial wake lock by default, we'll get more feedback on it.
I take the point to integrate this one in the next build.

This point can be dependant from the device. In fact my assumption (that partial wake lock was necessary) was based on test on a Archos 5IT. But this device has some special sleep policies : for example it can goes in an "hibernate" mode.
So probably the final choice , as for other tweaky params, will be to find out at the first run what is the device we are running on, and setting the best configuration for this device.

[Anonymous]

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

+1 for a build without partial wake lock. Any thoughts on getting some "creative inspiration" from a certain other open source SIP project as to how they're avoiding this?

[Anonymous]

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

Sipdroid use a partial wake lock as far as I know (not read all the code but sounds there is somewhere in registration process where a partial wake lock is put down). Not read how Linphone manage this point.

But to be sure, we should test it ourself. Since csipsimple runs as a native library, maybe behavior is different regarding cpu policy. And there is things really strange in Sipdroid (such as alarms that launch portion of code to check if network is present instead of relying only on network events... maybe there is a reason for that but as I don't know why...)

[Anonymous]

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

> alarms that launch portion of code to check if network
> is present instead of relying only on network events...

I don't know if this is related, but there is a problem in an XMPP client (Beem) when it, for unknown reason, miss some of connection/disconnection events.

That said, cSipSimple always disconnects and reconnects reliably for me.

[Anonymous]

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

Another thought how to minimize energy consumption: there is no need to re-register so often. SIP protocol suggests that you register as often as the registrar tell it. I think the typical value is several minutes.

Now, when the device is behind NAT (almost always), it is necessary to periodically refresh the relation, usually you need to do it more frequently. For that, you can use "empty" SIP messages, i.e. just a single CRLF, without headers and body. They are just ignored by the server, no answer is sent, so they are in every aspect cheaper than re-registrations.

I once owned a hardware SIP phone that used this approach.

[Anonymous]

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

Reporting success :-)

Since the app has an option to disable PARTIAL_WAKE_LOCK, I am running in this mode and battery usage has noticeably improved. I think it is now in line with or better than what I had when I ran Sipdroid.

However, it feels(!) like the device is not registered (or not responding to calls) more often then before, and sometimes I see the "Sip registered" notice the instant I turn it on. This is not conclusive, as I also upgraded to FroYo at the same time, and the the difference is not very significant even if it exists.

Anyway, I have a theory why this *might* happen: when you re-register in the background, you are not obtaining PARTIAL_WAKE_LOCK for the duration of this process. So, if registration cannot complete in 10 seconds (due to packet loss in the network or whatever), the system shuts down the CPU and registration retries no longer happen until CPU is woken up for some unrelated reason. Then retry (usually) succeeds and things are all right. But while it was sleeping, the server thinks that the device is not registered and do not send invites to it.

I am not sure if my theory has merit. But even if not, it seems a Right Thing to obtain PARTIAL_WAKE_LOCK at the moment when you are woken for re-registration and release it at the moment when re-registration succeeds or you decide to give up and fail. What do you think?

Thanks!

[Anonymous]

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

Re-registration is done by the native library. So it doesn't acquire any lock on the android system. But my think is that it's not linked to CPU if it automatically re-register when you turn on the screen. If when you turn on the screen it re-register, it means that network comes up (and this made csipsimple re-register).

If you are only on wifi, you might try to activate the *lock wifi option* (in network settings). Maybe (that's just a though), since Partial wake lock is not activated anymore, wifi consider it can goes in sleeping mode (disconnect itself or psp mode ? ).
So maybe worth to test with lock wifi option activated.

I can also try to use alarms methods that temporarily lock cpu each time re-registration should be done. But obviously if re-registration fails, it means that incoming call should also fails and alarm will not solve issue for incoming calls.

[Anonymous]

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

> If when you turn on the screen it re-register, it means that network comes up (and this made csipsimple re-register).

No, I don't think so. I have wifi sleep policy set to "sleep never" in WiFi Settings -> Advanced. And it registers really fast when I press power, establishing WiFi connection takes much longer.

As I said, the situation happens rather rarely, and if your theory was right it would happen to me every time the device goes to sleep for more than 15 minutes.

I wonder if it would be possible to initiate re-registration "by hand" from an android alarm handler instead of relying on pjsip's internal mechanism... Just a thought.

> But obviously if re-registration fails, it means that incoming call should also fails and alarm will not solve issue for incoming calls.

Obviously. My point is, *maybe* sometimes retrying process gets "frozen" when it takes more than 10 seconds, and we have it "would have succeeded after a retry but did not have a chance".

As I said, it's all speculation and not a proven theory.

[Anonymous]

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

(No comment was entered for this change.)

Summary: Battery consumption

[Anonymous]

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

Issue 204 has been merged into this issue.

[Anonymous]

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

I'm also looking forward for having a version of CSipSimple with PARTIAL_WAKE_LOCK being disabled to save my battery life.

It's very important to me for having a battery friendly client.

Thank you very much for creating and maintaining a great client.

[Anonymous]

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

Commenter 19, you can enable or disable the use of PARTIAL_WAKE_LOCK under Settings -> User Interface (in the dev. versions from the website, not in the market version).

[Anonymous]

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

Thank you egcrosser for letting me know. I'm using the dev version right now and I will report back the results.

[Anonymous]

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

I have found by setting the Reregister to 184 and Keep Alive to 100 (obtained by looking at SipDroid source), I can turn off Partial Wake Lock and not miss any calls on my Nexus 2.2 - 3g or wifi.

I am curious if others experience the same serendipity.

[Anonymous]

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

@krolaw, when you say "reregister" do you mean the "Register Timeout" setting? I've tried setting that to 184, and Keep Alive to 100 as you suggest, it still seems to only work intermittently.

[Anonymous]

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

Strange (works for me ;-) ).  Wifi or 3G?  If Wifi, make sure it is set to never sleep in system settings.  Are you using a Nexus?  Although it might be more network related as it works on a G1...

[Anonymous]

Originally posted by: tobias.p...@gmail.com

I am just starting to do some tests with CSIP and so far I configured a sipsorcery account with UDP connection and a timeout of 3600s and a keepalive interval of 120s and I receive calls and battery life seems to perform well.