![]() |
Re: SailfishOS 2.0 Nexus 5 CM12.1 Alpha1 | Sfdroid Pre-Alpha/Early Preview
Quote:
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 :D |
Re: SailfishOS 2.0 Nexus 5 CM12.1 Alpha1 | Sfdroid Pre-Alpha/Early Preview
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? |
Re: SailfishOS 2.0 Nexus 5 CM12.1 Alpha1 | Sfdroid Pre-Alpha/Early Preview
Quote:
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. |
Re: SailfishOS 2.0 Nexus 5 CM12.1 Alpha1 | Sfdroid Pre-Alpha/Early Preview
Quote:
|
Re: SailfishOS 2.0 Nexus 5 CM12.1 Alpha1 | Sfdroid Pre-Alpha/Early Preview
Quote:
|
Re: SailfishOS 2.0 Nexus 5 CM12.1 Alpha1 | Sfdroid Pre-Alpha/Early Preview
Quote:
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! |
Re: SailfishOS 2.0 Nexus 5 CM12.1 Alpha1 | Sfdroid Pre-Alpha/Early Preview
Quote:
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. |
Re: SailfishOS 2.0 Nexus 5 CM12.1 Alpha1 | Sfdroid Pre-Alpha/Early Preview
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. |
Re: SailfishOS 2.0 Nexus 5 CM12.1 Alpha1 | Sfdroid Pre-Alpha/Early Preview
i'm using sailfish 2.0.1.1 , if you tell me what test to do i will do it ;)
|
Re: SailfishOS 2.0 Nexus 5 CM12.1 Alpha1 | Sfdroid Pre-Alpha/Early Preview
3 Attachment(s)
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. |
All times are GMT. The time now is 07:21. |
vBulletin® Version 3.8.8