yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Original Android Development] rlaw:
I sincerely doubt you've achieved 7-8hrs of screen on time. The only kernel I've seen do that was faux's with eco mode on (only cores will be used, ever), sync etc off, maxfreq at 1134MHz, on wifi all day, min brightness etc.

The biggest power draw will always be the screen and there's not much you can do about that except use the lowest brightness possible and avoid dark themes. Why avoid dark themes? Our LCD screen has a backlight for illumination, each pixel is made up of three sub pixels (rgb), each sub pixels filters out a certain wavelength so the pixel as a whole can show the desired color. To produce black, all wavelength is filtered hence highest power draw (amoled is the opposite, almost zero power required for black, white highest power draw).

Undervolting probably results in a 5% savings of battery life at absolute most, I'd guess closer to 2-3% is more likely, if even that. And as noted, extreme undervolting can result in sustaining a given freq for a longer period of time hence higher power draw. Undervolting is really more practical for thermal management.

Yah. No way you get 7-8hrs screen on time with the settings you posted. That being said, this kernel is by far the best, with the most optimal balance of speed, performance, smoothness and battery life.

I can get just about 6hrs screen on time if I'm on min brightness, wifi on (with sync on, location reporting, gps/bluetooth off etc) without having to cap my freq or use a governor other than interactive - really good.

Maybe with very few background processes, sync off, location off, wifi on yadda yadda I'd be able to see 7 or 8hrs being achieved but that would probably be the upper limits of screen on time with this phone.

---------- Post added at 01:09 AM ---------- Previous post was at 01:04 AM ----------

And please don't take my previous post as confrontational or hostile, I'm voicing my opinion (I think you're exaggerating a bit) and would like to see picture proof of 8hr battery life on this phone. :)
[Nexus 4 Original Android Development] consolidate42:
You may have your doubts, but I wager you've not even logged actual numbers to measure your power draw.

I've logged my battery current over the course of an hour of normal usage @ the settings I've posted. The mA drain averages ~275mA, so the math works out (2100mAh battery). Granted the total screen time might be closer to 7 than 8, but I'm not going to lie about something like this.

I find that turning input boost off makes a big difference, I also use very few programs that sync, only gmail.

Sorry, but the 2-3% number you cite for undervolting sounds pretty inaccurate and needs to be backed up with some evidence. At stock voltage when idleing @ 304 /w screen on i recorded ~200mA drain compared to ~170mA with UV.That's a lot more than 2-3%
[Nexus 4 Original Android Development] dwang:
I think getting 8 hours of onscreen time is possible if u are maybe reading a book for almost 8 hours straight with wifi enabled, but getting 8 hours of screen on time over 12-14 hours seems pretty difficult.

The best i've gotten is 5.5 hours of screen on time and 17 hours on battery with wifi enabled.

Would love to get 6 hours of screen on time with 3g, maybe when 4.2.2 comes out with some of the proper hsic fixes.
[Nexus 4 Original Android Development] lazer155:
So when I am trying to undervolt the 1512mhz frequency, I select 1458mhz and 1512mhz as my minimum and maximum? It just seems like that would result in me not being able to adjust the 1.5ghz frequency because it is in use.
[Nexus 4 Original Android Development] _motley:
Hi everyone, so in reference to my above suggestions this morning, are we in agreement about why b12 and b14 caused reboots for some?

I think I counted one person on b12 that claimed they had one reboot and they hadn't adjusted voltages since they weren't rooted. However, I don't have a log in hand or any other info, so it is hard to say what caused it. Another user with b12 said it was more stable for them than any previous build and they were not excessively UV'ed. One user with b12 that did provide a log definitely had an interactive governor exception occur (new Google interactive in b12), but I don't know about his voltages at the time it occurred. I am guessing they were too low.

So, what do you all think about moving forward? b12 or b14? Which was more stable for you? Which was smoother? I still haven't had one reboot on either build and ran b14 for about 24 hours.

Decisions, decisions:confused:

Might try one more hybrid between b12 and b14 and see where that takes us.

Cheers,

motley
[Nexus 4 Original Android Development] jacklebott:
If there was an issue with not being able to undervolt while the frequency is in use, then no one'd ever be able to undervolt
[Nexus 4 Original Android Development] rlaw:
b12
[Nexus 4 Original Android Development] lazer155:
I'm having an issue with not being able to get system tuner pro to change my 304mhz frequency. I can't lower it. Everytime, I do it defaults back to what it was before, 725mv.
[Nexus 4 Original Android Development] rlaw:
Provide pictures next time you're at 7 or 8hrs screen on time with a description of settings, usage scenario, graph and app/process break down in battery screen etc.

---------- Post added at 01:51 AM ---------- Previous post was at 01:50 AM ----------

I'm assuming you mean voltage. Try trickster mod, it's free.
[Nexus 4 Original Android Development] _motley:
I figured you might say that:D. Did you like it out of the box with the default PowerHAL, or would you use the inert PowerHAL with interactive or ondemand?

P.S. b12 was very smooth, I agree
[Nexus 4 Original Android Development] lazer155:
Sorry, yeah voltage. I'll try trickster instead. Do you use the bootloop preventer feature?
[Nexus 4 Original Android Development] rlaw:
I use it the way it is right out the box with interactive governor.

Works a treat. :cool:

---------- Post added at 01:58 AM ---------- Previous post was at 01:57 AM ----------

Nope. As long as you test your voltage settings before hitting the option to save settings on boot, you'll be fine.
[Nexus 4 Original Android Development] mundixx:
Motley, I was that guy that had a reboot in b12, using interactive, and provided the last_kmsg. My voltages at that time were UV'ed to - 125 across all voltages so I guess that is already too aggressive? For the record I have a fast binned chip.

Now, I am using Interactive again on b14 with no changes to the settings and I've no spontaneous reboots so far.

I hope this information is detailed enough to help :D
[Nexus 4 Original Android Development] rlaw:
Fast binned is already uv -100mV by default, you undervolted from there by a further -125mV?

If so, that was almost definitely your problem.
[Nexus 4 Original Android Development] lazer155:
Is the save on boot, the checkmark at the top?
[Nexus 4 Original Android Development] rlaw:
No, the checkmark at the top is to apply your changes. By save on boot, I meant save your current settings and apply them on boot. Should've been clearer.
[Nexus 4 Original Android Development] lazer155:
If he meant he is using 600mv, then there is a chance that it will work since several other people have reported using the same setting with no issue in the spreadsheet.

So then the "set on boot" in the menu sets your voltages at boot? I just want to make sure I am not accidentally going to save unstable voltages on boot.
[Nexus 4 Original Android Development] _motley:
Thanks. Yes, that was very likely your problem on b12. The default boostpulse frequency was 1.29GHz in b12. When it pulsed at that frequency (and perhaps at the other mid-range freqs), that amount of UV in addition to what I have already baked in is too much. With b10, I have lowered the default boostpulse frequency to 1.02GHz (like stock). It could be this little difference or the way the governor handles the load, but at those low UV levels, I wouldn't be surprised if you also experience problems in b14.
[Nexus 4 Original Android Development] rlaw:
He was doing a global undervolt, that would put 1.512GHz at 925mV. I haven't seen anyone with a faster binned mention being stable under 950mV.

The lower frequencies are fine at low voltages but the power requirement uptick for each freq seems more logarithmic than linear.

Yeah, set on boot sets ALL your current settings on boot. This could cause conflict if you're using another app to play around with (ex system tuner pro you've previously mentioned). I would set only one or the other to set on boot.

A workaround if you prefer system tuner pro is to manually use trickster mood upon each boot to set voltage.
[Nexus 4 Original Android Development] JmPTaz09:
Running be 14 right now, all seems very nice and smooth, no reboot. For what its worth, I did not have any reboots that I noticed on 10 or 12 either. Is very hard to tell which 1 is faster or smoother between 12 or 14 without running them side by side, I thought both performed pretty nicely. That being said, I flashed a CM 10 variant and number 14 is running exceptionally well at the moment.

p s. I have been undervolting by 50 at all frequency levels (so 304 is at 700)
[Nexus 4 Original Android Development] popophobia:
So I've been using b14 and run a few stress test with higher voltage values, it seems fine. I'm backing down to b12 with similar voltage table and run the stress test again. I think the reboots are due to the voltages.

Thanks everyone for helping out.
[Nexus 4 Original Android Development] consolidate42:
I posted pictures of 4 hr @ 50% a few pages back.

That doesn't necessary extrapolate to 8 hrs at 100%, but you can use your imagination regardless.

And let me reiterate, just where are you getting this 2-3% number from?

987mV compared to 1150mV is about a 15% undervolt from stock. That literally equals to at least 15% less power usage from the cpu. Remember power = current x voltage. I'm going to be generous and assume that the screen drains 125mA as a constant rate for lowest brightness. At 100% cpu load, I'm measuring >1000mA current. That means that cpu power contributes to about 90% total drain. At the very least, I'm saving >10% power at 100% cpu load and between 5-10% at idle load (despite the ratio of cpu drain being lower at idle, the UV at the lower voltages is more aggressive) .

What numbers are you using to arrive at this 2-3% number because honestly it sounds like something you made-up on the spot.
[Nexus 4 Original Android Development] _motley:
Excellent, thanks. I will work on a new build integrating the best of everything we have learned. I'll keep checking back as more people comment. There was something about the smoothness of b12 and I would like to get that part back.
[Nexus 4 Original Android Development] mundixx:
That's good to know mate. I am already enjoying the smoothness of b14, so i can only imagine how smooth your smooth would be. Keep up the great work :D

Sent from my AOSPA Nexus 4
[Nexus 4 Original Android Development] mobilehavoc:
So far so good on b14 but b12 was just so smooth I could smell the butter coming out of the phone. Lol
[Nexus 4 Original Android Development] _motley:
LOL, thanks guys.
[Nexus 4 Original Android Development] air2k57:
Great work on your kernels motley! I'm definitely liking the performance and your kernel is the only one that works really well with T-Mobile data in subpar coverage areas. I literally have very little issues with data timeouts when switching to hspa+, unlike on others.

I've asked earlier, maybe I somehow missed the reply. But, what's the word on incorporating the color fix that matrix has? I know few other kernels incorporate it as well, makes whites look amazing! Pretty pweez :).
[Nexus 4 Original Android Development] iFalcon:
+1 on that color adjustment. Makes a very nice difference.
[Nexus 4 Original Android Development] _motley:
Thanks, I tried this fix before and some people didn't like it for whatever reason. I also wasn't sold on it. However matrix, franco, and morfic all have integrated this patch (partial revert) and people seem to like it. I will look at it again. I would also need to revert my RGB tweak to make it the same. If it looks good to me, maybe I will add back to the next build an take another vote. I am not sure if people have different screens or what, but I guess we'll see what happens. Still thinking about working out a sysfs interface to allow us to control these gamma settings.
[Nexus 4 Original Android Development] air2k57:
Maybe ;). Stock, compared to optimus g on sprint, colors on nexus seemed a bit dull. When I had it side by side while running matrix kernel, mine looked better. Maybe we all have different screens, you're right.
[Nexus 4 Original Android Development] ptesmoke:
Yup motley I think your heading in the right direction. I'm pretty sure my one reboot was due to extreme UV. Looking forward to your next :)
[Nexus 4 Original Android Development] rlaw:
That's what the numbers worked out to on my Galaxy Note, I'm assuming there isn't going to be much difference between devices.

And the 2-3% is about total battery life savings. Because obviously utilizing 15% less power at a given frequency doesn't translate to extending total battery life by 15%. The CPU isn't the only thing sucking juice, you've got the GPU, flash storage, radios etc.

The increase in efficiency has an impact equal to the percentage of contribution of that subsystem to the entire system. So let's say it's 15% in context or the subsystem. Great. In context of the entire system? Much lower. I think you've got this part down pat.

I think if you take whatever tool you're using to measure draw and record data from a standardized usage scenario over a sufficient period of time, you'll probably find that overall, undervolting has less of an impact in the mobile space than it does in desktop class machines where some truly incredible results can be seen.

The closest I can come to agreeing with you is that in specific contexts with a specific usage case in a hermetic operating environment (no auto sync, location reporting off, apps/processes blocked from accessing Internet etc), the undervolting results in a greater than 5% extension of battery life.

But real world with all the different hardware parts sucking down juice to function as they need to, I'm not expecting more than 5% extra battery life to burn through as the absolute best case scenario.
[Nexus 4 Original Android Development] lazer155:
This is a screen on time that I got about a week ago with b10. It was 7 hours with wifi and 3g on. I was near a wifi access point the entire time so 3g was not really being used but it was turned on and connected. It was inside and auto-brightness was turned on. All the default syncing was on (google now, location services, gps, gmail sync [my only app that syncs] ect.) Aldiko (book reading app) was being used for most of the time but a bit of browsing and sms messaging was done too.
[Nexus 4 Original Android Development] rlaw:
Impressive.
[Nexus 4 Original Android Development] consolidate42:
Sigh.

I do not know how to make it more clear for you. Your 2-3% number is way off no matter how you slice it.

Worst case scenario for my argument is that cpu power draw is the smallest contributing factor of total power draw - this is most likely true at the idle state because screen brightness and network connectivitys a constant (less variable anyway). EVEN at the worst case scenario, I measured a difference of 170mA UV vs. 190mA stock. This is ~10% decrease of TOTAL power drain in the WORST CASE. Under periods of higher load, the power savings will be greater as the ratio of cpu power contributing to total drain is even greater.

There is also no way for that you could claim a statistically significant 2-3% difference in battery life on your galaxy note. Unless you ran several controlled 'trials' the best you can do is argue that the battery savings from UV was not perceptible for you. Even a 10% increase in battery life is not perceptible to most people, but that is exactly why I took the time to take controlled measurements instead of idly speculating.
[Nexus 4 Original Android Development] rlaw:
If it is as you say, it is as you say.
[Nexus 4 Original Android Development] jazzboyrules:
I had one reboot on b12 because I UV'ed by 2 steps across all frequencies. I hadn't flashed the inert HAL. But on b14, I haven't had any reboot inspite of UVing by 3 steps. I am happy with b14. But I will be glad to try out the hybrid you put out and will use it without UVing to avoid any reboots.
[Nexus 4 Original Android Development] Hrithan2020:
Can you let me know what you are using to measure the drain?

Sent from my Nexus 4
[Nexus 4 Original Android Development] consolidate42:
If something is tautologically true, then it is tautologically true. But only if - it could still be false.

I've never seen someone go to such great lengths to indirectly imply that I could be wrong. :good:

CurrentWidget - I set it to read at 15 second intervals and log for 30 minutes; I take the average of all the readings.
[Nexus 4 Original Android Development] Hrithan2020:
If that is the case, you can't state these as facts. As you may be well aware of, these readings are hardly accurate and mostly approximations. Nevertheless, great work in monitoring all these and letting us know :)

It would be great, if some one was able to actually find out the current power draw. That will settle all doubts/questions about UV for Nexus 4 ;)
[Nexus 4 Original Android Development] consolidate42:
They actually are facts. :cool:

Currentwidget does not approximate battery current using voltage loss over time.... The readings are drawn from /sys/class/power_supply/battery/current_now, you can check it for yourself.

It is literally the only direct method of reading current. If you don't trust the system-level reporting of current, 'actually measuring the current power draw' would require you to open up the n4 and attach an ammeter...
[Nexus 4 Original Android Development] Hrithan2020:
Yes, I know that. I was talking about direct method only which is much more accurate. Not sure anyone will be willing to do with N4 . [ has been done for phones without removable battery ].
[Nexus 4 Original Android Development] consolidate42:
It is likely not so inaccurate that it would report a <3% difference in current as actually >10% Let's presume that the n4's battery is actually 2100mAh.

I know that my airplane mode screen-on time with all processes idling is ~ 11 to 12 hours. This roughly corresponds to an average of 180mA which incidentally is what the sys file is reporting. When I run my n4 at full cpu load with benchmarks or stability test, my screen-on time is ~2 to 3 hours; corresponds to an average of 800-1000mA which incidentally is what the sys file is reporting. Bear in mind that current draw at lower battery levels are slightly higher to compensate for lower voltage. The n4 maintains 4.3V at full charge and close to 3.7V at almost empty.

So unless for some bizarre reason the S4 pro defies physics by having higher cpu voltages result in lower current(?!), the system-level reading does not seem to be very inaccurate at all. Because incidentally(!?) its measurements seem to correspond to the n4 2100mAh battery's observed behavior pretty well.

This is all besides the point that it doesn't even matter if the sys file is slightly inaccurate. All that matters is that it is reasonably 'precise' - that is to say it reports consistent values for tests regarding cpu voltage levels.

In all my tests comparing idle cpu current draws (worst case scenario for UV helping to save battery), measurements for the the UV cpu were always lower than that of the stock cpu by 10-15%. I can calculate for you the approximate variance of the individual logged readings and then do the requisite number of trials for a level of statistical significance with which you are happy, but I'm pretty sure I've already done that because the approximate variance of the reported current divided by the square root of 120 (# of readings over a 30 minute period) is likely a small enough z-score to show that 190mA is statistically significantly different from 170mA.
[Nexus 4 Original Android Development] Hrithan2020:
Great!!

Yeah, I was really fascinated in knowing how extreme UV leads to higher drain. TBH, I am not sure how the current drain is reported by N4, but it would make sense that is would be reasonably accurate. [correspond to observed behaviour] . Agree with you that, repeated test should be able to give quite a good idea. But, even a 10 ma difference would still mean quite a difference %age wise. [say 190 ma to 170 ma turned out to be only 190 ma to 170 ma on UV], but still it is higher than 2-3% which other people say. But what I wanted to say was that direct measurement would undoubtedly lend more credence to your stats.

Also, it seems that the earlier UV tests using direct method had much higher display power consumption [350 ma if I remember correctly ; possibly due to the different screen/technology; avg of black+white possibly for AMOLED and they measured it directly if I am not wrong] which drastically understates the importance of UV. [which is why the 2-3% UV myth, if one can say so, came from]

BTW, can you please let me know your UV settings and the binning of your CPU. Till now, I have not done extreme UV [600 mv for 1026 mhz!!] and was sceptical how that would be stable. [ Have a faster CPU with min 384 mhz @675 mv , with a somewhat linear progression to others; modifying only -50mv or so at the higher levels from the already UV'ed motley settings]

EDIT: NVM, Got it, thanks to lazer. :)
[Nexus 4 Original Android Development] ethoss:
I have some news for my lockscreen lag. They only occurs when i'm on 3g network. No lag when i'm on WiFi. For lag I mean:

When I turn on the screen with power button there is a delay on displaying the lock ring and the animation of dotted rings is laggy...

Can I attach some log? Wich one? :)

Inviato dal mio Nexus 4 con Tapatalk 2
[Nexus 4 Original Android Development] batman368:
ok, i tested my UV settings, results are in the spreadsheet and here:

600	600	600	600	625	650	700	800	850	887	910	925	940	950

that's mV for different frequencies. it's aboslutely crazy how low i can go :) cpu is fast binned.

spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AnlqtEwFJwR6dE55WkZYSThEM3U4SGtKMVl2V1VqMmc#gid=0

i added i nice little diagram on page 2 of it. please enter all voltage values with decimal points, no commas, the diagram gets messed up by commas ;)

edit: ok, seems that values below 600mV are not sticking, and are also probably never applied. could motley say something about this?
[Nexus 4 Original Android Development] Remoteconcern:
The kernel locks the lowest voltage to 600mV. So those low end steps are being applied at that level. But otherwise, thats a really nice example, thanks :D
[Nexus 4 Original Android Development] ReD_AvEnGeR:
Can you add touch control (pgm) support ?
[Nexus 4 Original Android Development] elkhouri:
Got through a day on b14 with no reboots. Decided to try b12 again to see if it reboots, and it did. Got a last_kmsg this time too. Was doing some regular web browsing on Boat Browser when it happened.

The kernel is on all stock settings, no changed voltages, did not flash the inert powerHAL, and on Xylon 16 stable.
[Nexus 4 Original Android Development] jazzboyrules:
I am getting screen-on current values anywhere between 200mA and 400mA. I am curious what you did to make that go down to 160mA. I used the CurrentWidget as you did. Did you normalize the current readings?
[Nexus 4 Original Android Development] elkhouri:
Deleted.
[Nexus 4 Original Android Development] elkhouri:
Another reboot happened shortly after, same settings, except I was browsing this forum on Tapatalk. Will try flashing inert powerHAL again with b12.