Diese Seite ist nicht auf Deutsch verfügbar.

Hint for anyone reading this and not knowing what this is about: forget it, skip to something else. It may be outdated although it is less than a few days from now (most of it was written on 26.06.2019).

I documented it in this way to make it more likely for others to spot mistakes in the way I interpreted the logs.

Spoiler: with my setup csi_battery_saver is the winner.

1. What did I do?

Enable debug logging, two different sets of modules, each for about one day.

smacks, smacks_offline and cloud_notify where active in both setups. They differed regarding the set of csi modules used:

Day one: csi_battery_saver

Day two: csi_simple, csi_grace_period and csi_muc_priorities. All public MUCs joined by the test user are set to low priority for csi_muc_priorities (done using gajim). There is only one MUC left in normal priority, but it only has four members.

Both days where similar: mobile internet connection (no wifi) except in the middle of the period when being at home. Similar usage of phone while at work.

The log files where grepped using

grep -h to..user@domain/Conversations.random var/log/prosody/* | grep Sending.c2s | sort > /tmp/ids

and the remaining timestamps where evaluated.

Most of the lines contain presences sent by MUC participants.

2. Results

2.1. Server logs

The first plot shows the difference in time between one line and the next (difference == 0 have been omitted, otherwise they’d completely fill the baseline). This plot clearly shows the differene between both setups…


…but I wanted to plot histograms nonetheless. First day, csi_battery_saver:


Second day, csi_simple and friends:


It seems that csi_battery_saver much better bundles the transmissions into bursts.

2.2. Android

During the days I noted what Android (Lineage 14.1 on a S4 mini) said about Conversations' (2.2.1, without push) battery usage and took some screen shots. Especially the time for mobile radio interface active (or whatever it may be called on english phones) went up much faster the second day (csi_simple and friends). Battery usage is clear, too:


I merged two screenshots to show quality of radio signal, wifi, phone active and display on. Marked areas correspond to the histograms shown above.

3. Code details

Changeset of community modules: da2d58208574 mod_muc_defaults: Allow setting of name and `description …

4. Notes

4.1. XEP-0286

Zash pointed me to XEP-0286:

So, other than maybe tweaking factory defaults or installing an unsafe 0138, there is nothing a prosody operator can do about it.

4.2. https://issues.prosody.im/1127

This bug was open and the reason why I didn’t use csi_battery_saver in the first place. But it actually seems to have been fixed some time ago:

Changeset: (75930e4c2478) mod_csi_battery_saver: flush queue on smacks resume instead of smacks hibernation
User: tmolitor
Date: 2018-06-08 17:39:43 +0200

4.3. Bugfix in mod_csi_muc_priorities

However, Zash pointed out:

I think the poor performance there is caused by mod_smacks not working with mod_csi_simple, since it gets capped to ~60s after a while (probably a disconnect+resume) and mod_smacks has a 60s timeout.

Letzte Änderung: 04.07.2019 21:35
Jens W. Wulf