[KERNEL] marmite v10.6 final

neosynthesis said:

Hi Erythnul, thank you for your info. Like many others here, I'm very interested in prolonging my Nexus S batt life. I'm on Marmite 4.83 now and running BetterBatteryStats on latest MIUI US JB rom. I couldn't find the advanced root functions you're referring to. Is this in the BetterBatteryStats app?

If you don't mind, maybe write a short tutorial on how to use the BetterBatteryStats tool to troubleshoot our battery woes. That'll help us out a lot. Thanks kindly.

Click to expand...

Click to collapse

Sorry it took me a while to respond, we were having festivities as my sister gave birth almost 2 weeks early. A new nephew!

Bedalus, if you feel this post should be in its own thread instead of in here, let me know and I'll move it asap.

Anyway, I wrote up a tutorial with pictures for everyone on BetterBatteryStats and analysing battery drain. And also just a little bit to show off my battery life after what I feel is a day's normal use. It's a full cycle, usually I'd charge the battery somewhere in the middle of this, to keep it from degrading sooner than it should. The tutorial will basically be a description of how I'd go about analysing any problems I'd have with battery life, from basic to advanced.

Before I begin, a quick disclaimer: I'm running ParanoidAndroid 2.13 on Marmite 4.5, I haven't had time to update either lately, and it's not the most battery-friendly combination I've ever used. I'm still getting great battery life, but it could probably be a little bit better. Won't matter that much though. Also, your mileage may vary depending on many factors, mostly your usage pattern, but also screen type. I have an i9023 Nexus S. It's an LCD screen, not super AMOLED, so I don't know how much/little battery they drain compared to the LCD. Using a black or mostly dark background will help for those screens. On LCD screens, this doesn't matter, only brightness level matters.
I will be keeping it simple, as I am not a programmer and started out knowing as much as anyone else about all this. All this information I slowly gathered from these forums, personal experience and some Google searches. I may be wrong on some things (though I got most of it right) and take no responsibility for any problems, though none should occur.

So, you're having battery trouble?

First off, lets get the basics out of the way. My setup at the moment is this:
As mentioned, PA 2.13 and Marmite 4.5 on an i9023. I never charge my battery above 90% (using BLX). I run no battery saving apps such as Juice Defender or similar things. Never overclock, never undervolt. BLD at 1.5 seconds. I keep my brightness at the lowest unless I don't have any other choice, wifi and data always on (disregarding exceptions). GPS and location services are on, but location reporting (Latitude inside Google Maps) and Google Now are usually on, but for the purposes of this tutorial, they were off (Battery drain impact: ~30-45 minutes of awake time spread over 24 hours.). Turning GPS and Location Services off will save you some more battery and awake time, for this cycle I forgot to turn them off.

High drain problems.

I feel that any Nexus S user should be able to get at least 3 hours of screen on time and still have battery left to sleep for ~17 hours, on a full cycle. This means 20 hours of effective use, or 4-4.5 hours of constant use off the charger. If a phone is idling well, it should use barely any battery at all, and only wake up when absolutely necessary. For me, the best way to analyse what processes are keeping my phone awake has been BetterBatteryStats. I will be assuming that it's installed and set up. Easy enough to get, it's on the Play Store (support the dev! ) or free here on XDA, just a search away.

To start analysing, first install and set up BBS (if you haven't done so already). BBS is not a very intuitive app, as it assumes that you know more than most people do about the internal processes and workings of the phone. Setting it up is easy enough though, and I won't be going into the details too much. Some of it I know, some of it I'm not too familiar with and I prefer to keep this outside of the realm of speculation. After installing BBS, start it up and hit the menu button to get to the Settings. Scroll down and tap on Advanced, then turn on the Root Features. This will allow BBS to read network usage from apps (not very critical, but nifty) and dump the Alarms sent by the system and apps (useful, but complex). After this, you'll be prompted by SuperUser or SuperSU to grant it access, and you're good to go. Fully charge your phone and start a new cycle. Use your phone as little as possible and do not reboot it or charge it in between. When the battery gets to ~50%, you'll be (more than) ready to find out where the problem is. You can also use your phone as usual, but this will cause the stats to be less easily interpreted, as your usage will also keep the device awake.

Why shouldn't I reboot or charge?

BBS will automatically create a reference point when your phone is unplugged from the charger, and will be ready to read the records on a moments notice. This valuable information is lost when the phone is rebooted, and recharging will reset the reference point. For an accurate analysis, please try to avoid this

On to business.

Now, the real task is going to begin, analysing the stats. Here's a link to an imgur album, with screenshots of my stats and battery life. I'm trying to use all of the pictures and make this tutorial look nice, but this is one of the longest posts I've ever written here, so for reference, this is all of them.

First off, check your normal battery stats screen, and the deeper stats (tap the graph).




These are my stats. Almost 20 hours on the clock, 14% remaining. ~3,5 hours screen on time and ~40 minutes of music. Not too bad (especially considering I started on 90% ). You can see there's some awake time. Part of that is music, part of it is Google Services (Location Services, Syncing) being annoying. The drain from Services is pretty minimal though, as you can see from the graph. The straight parts would probably have been somewhat straighter if it hadn't been syncing.

If your Nexus doesn't get these kind of times, something may be wrong. If it's a hardware problem, unfortunately I can't help you, but if it's software related (faulty kernel, troublesome app, buggy ROM), it's easy to track and fix. Let's fire up BBS.



You'll be greeted by this screen. Compare Deep Sleep times and Awake times to your screen on time from the previous pictures. (My total awake time was ~4.5 hours, 3.5 hours screen on time, ~30-35 mins music while screen was off, ~20-30 mins Google services.) If your device isn't sleeping properly, your Awake time should be significantly higher than your Screen On Time+Time media played (or +whatever other things you consciously keep the device awake for). Deep Sleep will be significantly lower, if present at all.

Switch to kernel wakelocks.
If something is seriously messing up, this is where you'll see it first:



In my picture, all is well with the world. No unseemly wakelocks here. PowerManagerService is basically a name for all the userspace processes keeping a Wakelock, these are shown in the next part of BBS, Partial wakelocks.
If you see any large wakelock spikes in Kernel Wakelocks, either tap the (?) next to it (if it's there, not all problems have been indexed by the dev of BBS) or Google it. Or ask me, and I'll either know or Google it and speculate for you

Reading these stats may seem complicated, but it's not all that hard. Most important are the total time and the count (cnt). This shows how many times the device is awakened by the specified service and how long it's kept the device awake.

Some of the problems that occur here are truly complex, and may be caused by too many things to go into here. Two quick examples from personal experience:

• My internal SD had a corrupted block, Android kept trying to read it (I didn't know this, but noticed high drain). mmc_detect1 wakelock kept showing up. I didn't know what to do with it, Googled around, found it had to do with mounting, had Windows check the filesystem (and repair it) and remounted the SD. Problem solved, no more wakelocks next cycle.
• After upgrading to JellyBean, one of my usual apps was causing a buffer overflow in the audio interface whenever it tried to gather environmental noise from the microphone. High drain occurred with no identifiable source, the app didn't show the drain because the overflow happened inside the kernel. I can't remember the name of the wakelock, and I had to do to some deeper digging to get to the root of it, but it was here and if I'd Googled sooner I would've known without resorting to more drastic measures to test my device's idling (Using DDMS from the SDK, a tutorial for some other time, if this doesn't help).

On to Partial Wakelocks:



These are all the user processes asking for time. In my case, obviously, music is the lead contender here.
Again, Google Services kept it awake quite some time, but spread very thinly. 1160 wakeups spread over 19 mins and 1550 wakeups spread over 9 mins. All of this amounts to negligible amounts of constant awake time, and can usually be disregarded.
Once again, if there are any unusual spikes, investigate further.

I seem to have forgotten to take pictures of the other screens of BBS, but these 3 are the most important anyway.
Alarms can tell you which app is sending most of the wakeup messages, which is really useful and I wish I had that screenshot, but I don't. :/
Network Stats is kind of self-explanatory, as is CPU states.
Process is a screen I know practically nothing about, but if I remember correctly it shows how much CPU time some processes requested. I recently charged so my stats are kind of empty now, so I can't check :/

Concluding

Okay, so this tutorial wasn't as good as I wanted it to be because I have no battery problems at the moment. I will be happy to interpret anyone's battery graphs/BBS stats, however, so hopefully that makes up for it a bit.
Also, hopefully I've at least shown how to work BBS and interpret the basics. Any questions/screenshots can be sent to me by PM. (Or if you reply, please don't quote this entire post )

Thanks to Articudos, here is a link to the thread where I learned a lot of what I know about wakelocks back when it was first posted, this knowledge is invaluable if you really want to delve deeply into the system. It's much more detailed and accurate than my attempt at a tutorial here, so I fully recommend reading it, it's practically guaranteed to solve your wakelock problems.

[GUIDE] The Total Newb's Guide to Wakelocks

Also, please let me know what you think about the tutorial and if I can improve it somehow, it probably needs work. Thanks for reading and good luck!

bedalus said:

I know I said I was taking a break from building, but...

v6.6 is here: http://goo.gl/HvUrp

-Merged to Linux mainline v3.0.50
-Fixed the GPU code.

In the PLL check that I created for v6.5 I somehow accidentally changed a different check. Sorting out this GPU OC at 1.1GHz has been a real chore, so again, I'm taking some time off building, but I couldn't leave the version matrix with an error dangling at the top. Enjoy!

Click to expand...

Click to collapse

So now I think the time has come to thank you bedalus:

For your energy you always take in this development.
For your unbelievable patience.
For your sleepless nights that you spend with and for us.
For your will to give your best... and correct any little mistake soon as possible.
For your friendly answering of stupid questions.
This is what make our community make what it is.
Maybe it sounds gay but its the truth.
And I hope the most agree with me...
Thanks a lot man.
S.R.

Overclock! Undervolt! OC UV OC UV...

Shut up!!

Hello ex-colleagues, please have a good read here. I quote this from DorimanX from SGSII Kernel Dev. (Yes for those who know, I was a Nexus S user) Basically he had a talk with a chip developer whom has watched his thread and decided to say something that, most if not all of us, are confused and very deficient in knowledge - OverClocking/Undervolting. Visit his post here and please thank him for sharing.

I bring here of what you can expect. Dear Bedalus, you might want to add this to OP for educating adamant humans on OC, UV...
Gist of it? What may be true for one may not be true for all!

Merry Christmas to Bedalus, guys and girls on this thread, and whole xda community. Enjoy with familly and in gifts. :beer:

Sent from SpeedMachine i9100

MTP also work with MIUI

bedalus, the great
I have tried you V1 kernel on MIUIandroid ver 2.7.13 and gladly report that MTP work on Windows XP!!!

As MIUI don't have option in Setting>Storage>xxxxx ; here's my trial:

1.from Play store search and download "USB mode switch for SGS1 on CM" (need root)
2.Open and select "change to MTP" pop up will ask for reboot then reboot
3.after reboot plugin USB cable and MTP would be found but driver won't install
4.Disable "USB debugging" then MTP driver automaticly installed