Short keepalive drains battery

[rkralovic]

Hello,

In my experience xabber heavily drains my phone battery. A bit of investigation suggests that a big culprit here is a very short keepalive timeout (30s) for xmpp connections. Another side effect of this is a big data consumption (about 2MB / day with 3 jabber accounts, not used at all).

Im currently testing increasing values of keepAliveInterval and keepAliveResponse in res/raw/smack_config.xml to 1800s. So far, my battery drain seems to be normal again.

Would you mind increasing those values or make them configurable?

[a-iv]

Actually we plan to make it configurable.
Note that large keep alive interval will increase chance to loss messages over bad GPRS connection.

[SilicaAnimus]

There is a chance for implementation of this feature in next build?

It shouldn't be hard to do, but will be very useful.

[martin-steghoefer]

Seems to be a duplicate of #152.

[HerrCypher]

a-iv said "Note that large keep alive interval will increase chance to loss messages over bad GPRS connection."

That's what TCP-retransmissions are for.
I understand that a low keep-alive will more likely bump any not-yet-sucessfuly-retransmitted messages to the its destination in a lot bad-GPRS cases, but (for me) it's not worth the battery drain.

--- Slightly off-topic because it's not directly Xabber related ---
Another reason for drain are some misconfigured Android-devices. (I only saw it on my HTC-phone, Samsung seems to handle it well) Let me explain:
There is a UMTS/HSPA configuration parameter "ro.ril.fast.dormancy.rule" in /system/build.prop which can be set to "1" or "0". When set to "1", it is -SUPPOSED- to save battery by changing some parameters like the time before the phones transmitter goes back to IDLE after it sent something.
In reality it looks a bit different for some phones:
As soon as only one byte of data is send over 3G, the transmitter will go into full-power mode for a few seconds when this value is set to "1". So, Xabber sends a PING and the transmitter ramps up for ~5 seconds, only to transmit this one tiny PING-packet - this was definitely not worth it.
When this value is set to "0" it actually does what the cell-tower wants the phone to do: Instead of going into fullpower mode immediately, it goes from idle mode into a "low power" mode (keyword: CELL_FACH) and sends the PING-packet in just one short burst, which takes maybe ~10ms of time.
Obviously 10ms low-power (+ a few low-power seconds until it goes back to idle) will use less battery than 5 seconds full-power.

TL;DR and summary:
On a misconfigured phone, Xabber will cause the transmitter to be in full-power mode every 30 seconds for ~5 seconds.

[horazont]

TCP keepalive is for detecting a broken connection quickly, and thus, reconnect cleanly. During the dead-time during which the connection is unknowingly broken, messages will be sent into the void. TCP keepalives are not used, to my knowledge, to have quicker re-sending.

The proper long-term fix to losing messages during unknown dead-time of the connection is to use xmpp stream management, for which issue #67 is already opened.

Nevertheless, a configurable keepalive time would be desirable for saving battery live, especially once stream management is implemented.

[andrewnenakhov]

@horazont stream management has some flaws in design. Better than nothing, but not too good for proper message delivery control. Anyway, current Xabber battery usage is very modest, so I close this issue