I'm using multirom since day one.

If have a second SFOS to test SF updates and check if the patches i use are working, and i test the kernelsbefore i install them on my main SFOS installation.

By the way a new kernel is on the way with updated wifi drivers and some power managment improvements, i hope to release it this evening.

Regarding the powersave when the phone is suspended, if the phone is in idle state the tick rate does not matter that much, since kernel 3.4 is nearly running tickless when idle. Sadly full tickless mode was introduced in kernel 3.10 and i haven't found a working 3.10 version for the N5.

EDIT: Seems francos kernel for the N5 is tickles...looks like i've got some work to do

Concerning the battery drain, when the screen is on, maybe we are lacking hardware accleration of the GPU? Scrollingthrough the apps menu can bring the CPU usage up to 100%.

Edit:

I checked the CPU usage in Android 6 it is about 30-40% lower. This is way better, but this alone can't be the cause for the huge difference in battery life...if this is true.
Has anyone used the Nexus5 with Android 5.1 before switching to SFOS and can confirm that there is such a huge difference?

I think the UX works with GPU acceleration, too. If you run AIDA64 and select the GPU tab and move through applications/scroll around, the GPU usage ramps up to anywhere from 20% to 60% on my device.

I can confirm the huge difference. I used my N5 on Copperhead, which was 5.1.1 Lollipop, and it lasted literally 3-4 days without Google Play services.

Oh man, that is exciting!

Sorry, i was wrong...but since no actual N5 kernel is tickless(nearly all use CONFIG_HZ=100) this can't be the cause of the battery drain.

No worries! And yeah, I'm with you there. I'm fairly positive it isn't the GPU, and my CPU usage hovers around ~8% while the screen is on. Draw is about -110mAh at idle. It seems to behave a small amount better when I manually set my ofono TechnologyPreference to umts rather than selecting "prefer 3G" in settings.

Power drain is consistent regardless of which radios I disable or enable, so I'm not sure the radios are actually being turned off. If I turn off WiFi, Bluetooth, etc., it still draws an identical amount. This seems a little strange to me. Maybe the root here is the radio management?

Pure speculation, of course. Doesn't hurt to get it out there though!

I speculated on syncthing, removed it and voila battery life is better as the phone sticks to 3G since a day though i have set it to 4G in the settings:-)

In the past sensors have caused major issues on battery life, i have about 1.5%-2.0% here for both sensor processes with sfos 2.0.5. Can someone drop his numbers and sfos version here, especially lower sfos versions would be interesting.

Hi,

it's the same numbers for me, but they haven't changed during the updates(i'm now on 2..0.5.6). Disabling unneded sensors doesn't lower the CPU usage much. High usage only occurs when the sensors process crashes, which happens sometimes.

i'm using sailfish 2.0.1.1 , if you tell me what test to do i will do it

Have been following this thread with great interest - even without N5. However, I think we have similar problems on other devices.

I'd like to confirm the significantly larger drain in SFOS when compared to Android. At least, that was about a year ago on Nexus 4. As far as I remember, on Android, I could get about 2x longer on a single charge than in SFOS these days (SFOS did improve over a year on N4, at the beginning, the difference was even larger). So, the battery life difference is, in my experience on N4, similar to what as been suggested by some of you on N5.

Whether the difference is due to radios not switching off is hard to say. At least, as reported by rfkill interface at /sys/class/rfkill, the Linux kernel thinks the bluetooth and WiFi are as I expect them to be on N4 (and on OnePlus X). I have never seen any discrepency on the radio state when following rfkill interface by collectd. Whether Linux kernel gets fooled, that's another question.

Finally, when reporting CPU usage on sensors, I guess it would be great to specify how you measure it. If you use top then you are measuring against CPU time. Alternative is to measure against the wall time taking into account time which device was sleeping. An example logs for 24h of CPU sleep and sensor related sensorfwd and sensors.qcom processes are attached. These were recorded on OnePlus X, 2.0.2 and, as you could see, sensors account to 0.15% of wall time. Taking average sleep of 85% over that period, we get 1% of CPU time for sensors on this device.

While different hardware, I hope that these observations are of use for you as well.