Database Users

Clock speed

I'm running the cm 7 build 32. I was wondering how would I clock my cpu for better battery life?
Sent from my HTC Glacier using Tapatalk

What's the best cpu controller?
Sent from my HTC Glacier using Tapatalk

Hijacking your own thread? Heh.
CM7 comes with its own CPU adjustment capability. No 3rd party app is required. From a Home screen, press the options button, select Settings>>CyanogenMod settings>>Performance. READ the warning in the pop-up window. Press OK. Select CPU settings. Set your min and max, etc. Complain publicly when your level of overclocking produces heat, battery consumption, and software failures. Do the same when your level of underclocking produces unwanted behavior.
Lather, rinse, repeat.
There are 3rd party applications that can also adjust CPU clock speed, and adjust depending on usage / battery consumption. The most popular is SetCPU. Another is CPU Tuner.
There is also another Android kernel that some users are using with CM7, which has yet again some rules for modifying performance as states change. It's called the "smartass" kernel.

I personally recommend leaving the clocks alone, especially in the cm kernels. Zinx has stated numerous times that he hasn't modified any of the voltages, so overclocking isn't the best idea. Also, underclocking can cause more battery drain than just leaving it as is.
These phones are fast as is, no need to go crazy and start messing with them other than to show off your quadrant scores.

Well I'm looking to set for better battery cause I do a lot on my phones. I already killed the cm7 in one day without charging. I just wanna make it where it last the day
option94 said:
I personally recommend leaving the clocks alone, especially in the cm kernels. Zinx has stated numerous times that he hasn't modified any of the voltages, so overclocking isn't the best idea. Also, underclocking can cause more battery drain than just leaving it as is.
These phones are fast as is, no need to go crazy and start messing with them other than to show off your quadrant scores.
Click to expand...
Click to collapse
Sent from my HTC Glacier using Tapatalk

Under and Over Volting Madness?

Since we are all wondering what is responsible for this rash of bricks I thought I would start a topic about it. I'm hoping some of our electrical engineering crowd will pipe in on this.
First of all I'm not an engineer and all my knowledge of electronics comes from the practical and theory side of being an amateur radio licensee and a tinkerer of electronic devices.
I think that undervolting is just plain crazy. Our phones are devised to perform in a certain manner at a specific range of voltages. Circuits that are under volted tend to destabilize and do strange things. Resistors change the circuit and the wrong input voltage can change eveything downwind so to speak. Capacitors that are undervolted may not even fire at all. With the advent of LSI's a component may get smoked and you won't even get the satisfaction of smelling the magic smoke (acrid burned smell)
Now over volting definitely has much more applicability here because it's just a plain fact that juicing the cpu results in higher clock speed. Problem here is how to dissipate the heat generated. If we were talking about a desktop we could put on a big heatsink and fan and get decent results. If we wanted to go faster we could do liquid cooling and direct freon injection (phase change) on cpu if we really want to have some fun (if anyone is interested in a world record Epic OC attempt on liquid nitrogen send me a PM). However, none of these methods is going to work well on a phone if you want to keep using it to make phone calls.
From my perspective we can easily OC any processor 10-15% without worrying about heat problems and no under/over volting needed for most phones. As mentioned in another thread, to paraprase Duracell, some can take a licking and some will quit ticking. However, outside of this narrow range we are literally asking for odd kinds of trouble. Just like what we have seen of late...
Sent from Bonsai 7.0.3

Well there is nothing wrong with undervolting..we just need to take things a step at a time...instead of undervolting everything doing 1 change at a time would be much more ideal as its easier to root out problems. One thing I notice is lately these things are released in form of 10-20 changes to try to get better then the kernel before it..instead I would rather see isolated test kernels of 1 thing at a time...so lets say UV ram was the culprit(not saying it is)...but maybe LCD UV is ok..and thats probably what most of us wanted
In my case I was running Genocide and was getting really good underclocks(better then most people) and things were stable..when I saw LCD underclocking on the Vision I just couldn't resist...even though I noticed problems from the get go and my intuition was telling me to go back to Genocide as I had better undervolts there anyways the greed of having LCD undervolt was too much to give up.
What ultimately got me was when I saw the thread about the issue in the kernel...I paniced as I have been having issues and proceeded to shut down my phone to get back into clockworkmod...if I didnt do that my phone would probably still be alive...
So ironically what bricked my phone was not only the kernel itself but the warning about the possible brick lol...thats why I quickly put up the warning to others not to panic and shut down their phones following my footsteps...I dont blame anyone but myself..
There will always be sacrifices along the way..thats just how development is...

I agree,I think we are going down the wrong road when it comes to kernels,but everything is trial and error,just wish more time was spent testing; Not just "hey it boots,testers like it" 2 hours later its uploaded...
Sent from my SPH-D700 using XDA Premium App

ecooce said:
I agree,I think we are going down the wrong road when it comes to kernels,but everything is trial and error,just wish more time was spent testing; Not just "hey it boots,testers like it" 2 hours later its uploaded...
Sent from my SPH-D700 using XDA Premium App
Click to expand...
Click to collapse
Well as I said it would have been nice if we got the kernel features separated...aka 1 kernel with UV ram, one kernel with UV CPU and one kernel with UV LCD..then 10 days later if there were no issues go to UV CPU + LCD kernel and UV RAM + UV LCD Kernel..and then if everything is ok 10 days later merge them all into one..
My regret is not bricking my phone but the fact that it was bricked without providing much use...at the very least if my phone was bricked during a UV ram only test for example we would know where the issue was and not go that road..instead we are now stuck guessing the possibilities...
I guess our ambition is getting the better of us :/..slow and steady wins the race...

I totally agree with you about all the changes at one time being detrimental to good development. I've brought this up several times with the Bonsai Team. The problem from my perspective is that if you change 20 things and you have a problem you have no clue about what screwed what. Making one change and making observations is the hallmark of scientific testing. Now sometimes doctors use the shotgun approach, but only when they don't know what will work and someones life is on the line.
Sent from Bonsai 7.0.3

Top Nurse said:
I totally agree with you about all the changes at one time being detrimental to good development. I've brought this up several times with the Bonsai Team. The problem from my perspective is that if you change 20 things and you have a problem you have no clue about what screwed what. Making one change and making observations is the hallmark of scientific testing. Now sometimes doctors use the shotgun approach, but only when they don't know what will work and someones life is on the line.
Sent from Bonsai 7.0.3
Click to expand...
Click to collapse
Yeah I agree as well, however these are regular guys and gals that do this in their own free time and if they compile one thing at a time I believe it becomes way more time consuming. It could literally take months or even years to completely shake down a build, going one by one. Bleeding edge is the only way it can really be done in an open source/freelance environment like this.

epic4GEE said:
Yeah I agree as well, however these are regular guys and gals that do this in their own free time and if they compile one thing at a time I believe it becomes way more time consuming. It could literally take months or even years to completely shake down a build, going one by one. Bleeding edge is the only way it can really be done in an open source/freelance environment like this.
Click to expand...
Click to collapse
your not compiling line by line...your just compiling 1 feature at a time...it may take more time to compile, but you also end up saving time on debugging.
I mean its up to the devs to do their own thing, we can't exactly tell them what to do..but we can offer our suggestions..its up to them if they wish to try it that way or not.
And bleeding edge is not how its done in an open source environment..in an open source environment a feature is tested 1 at a time by forking the tree..then when its been properly finished and tested it gets merged back into the main tree for a release. If it fails to hit stable by time of main release it rolls over to the next release.
Of course everyone has different development policies but the above is a very common one.

Definitely agree about being real careful with undervolting just to squeeze a few percent out of the battery life. Top Nurse for not-an-engineer you are essentially correct about disrupting circuits especially transistors and diodes that function on a specified voltage drop. I, myself, thought I bricked twice only to find out I had undervolted my sleep speed of 200 Mhz by 125 mV essentially bringing it to 100Mhz. The interesting thing is Genocide has all this undervolting and 1.4Ghz speeds and yet I have not heard of any rash of bricks there. Maybe that kernel should be used as a comparison baseline.
Do you BONSAI?

If I remeber right Genocide dosnt UV the RAM...
Sent from my SPH-D700 using XDA Premium App

ecooce said:
If I remeber right Genocide dosnt UV the RAM...
Sent from my SPH-D700 using XDA Premium App
Click to expand...
Click to collapse
Does it undervolt the display?

mattallica76 said:
Does it undervolt the display?
Click to expand...
Click to collapse
no it doesnt, but i dont think display is the issue..also genocide doesnt have BFQ..only CFQ

mattallica76 said:
Does it undervolt the display?
Click to expand...
Click to collapse
No vision kernel was the first kernel publicly released that uv the screen and ram
Sent from my SPH-D700 using Tapatalk

MysteryEmotionz said:
No vision kernel was the first kernel publicly released that uv the screen and ram
Sent from my SPH-D700 using Tapatalk
Click to expand...
Click to collapse
I do believe the bonsai beta 4.1.0b9 kernel had the display undervolted as well, and I believe the BFQ was enabled by default...someone correct me if I'm wrong. More commonalities I'm sure.

mattallica76 said:
I do believe the bonsai beta 4.1.0b9 kernel had the display undervolted as well, and I believe the BFQ was enabled by default...someone correct me if I'm wrong. More commonalities I'm sure.
Click to expand...
Click to collapse
I found this changelog for bonsai:
- Voodoo color
- Undervolting in several modes including Screen and RAM at certain cpu frequencies
- Overclocking and underclocking configuration for 100mhz-1120mhz is now standard
- Read_ahead tuning to 4096 bytes
- Volume switch provides silent and vibrate control
- Upgrade to CWM 3.0.2.4
- Reduced battery % limit to 5% for Camera, VideoPlayer, and MusicPlayer.
- Increased windowsmgr refresh events_per_sec from 60 to 68
- Updated Maps.apk
---
I dont see BFQ..unless they always had it...
One thing I do notice with Genocide vs VisionKernel is on Genocide kernel 100mhz never really worked...and i odnt mean crashing...I used CPU Spy and it never showed 100mhz..on VisionKernel I did have it hit 100mhz a few times..
Edit: I see BFQ was added on the 31st - r458 - Add BFQ scheduler from Paolo Valente

gTen said:
I found this changelog for bonsai:
- Voodoo color
- Undervolting in several modes including Screen and RAM at certain cpu frequencies
- Overclocking and underclocking configuration for 100mhz-1120mhz is now standard
- Read_ahead tuning to 4096 bytes
- Volume switch provides silent and vibrate control
- Upgrade to CWM 3.0.2.4
- Reduced battery % limit to 5% for Camera, VideoPlayer, and MusicPlayer.
- Increased windowsmgr refresh events_per_sec from 60 to 68
- Updated Maps.apk
---
I dont see BFQ..unless they always had it...
One thing I do notice with Genocide vs VisionKernel is on Genocide kernel 100mhz never really worked...and i odnt mean crashing...I used CPU Spy and it never showed 100mhz..on VisionKernel I did have it hit 100mhz a few times..
Click to expand...
Click to collapse
On the stock Bonsai 4.0.1 kernel, it would not scale down to 100mhz with the conservative governor, but it would with interactive. The 4.1.0 b9 kernel fixed the issue and it would scale to 100mhz with no problem. (other than bricking your phone)

mattallica76 said:
On the stock Bonsai 4.0.1 kernel, it would not scale down to 100mhz with the conservative governor, but it would with interactive. The 4.1.0 b9 kernel fixed the issue and it would scale to 100mhz with no problem. (other than bricking your phone)
Click to expand...
Click to collapse
Hmm..does any other kernel achieve 100mhz?
When I was looking at CPU Spy usually at max it would be like a few seconds on the 100mhz frequency...I would think when shutting down a phone 100mhz frequency might be used during a short interval..the only other person who claimed he got same thing and not on power down but at lock screen..which I know after waking it hits 100mhz...there might be a pattern here :/

So there are a lot of similiarities between the 2 bricking kernels and differences to genocide. Since there is no charging light when plugged in, it is still some catastrophic failure. Would RAM or video failure be enough to prevent the phone from charging? Or turn on the charge light?
Do you BONSAI?

kennyglass123 said:
So there are a lot of similiarities between the 2 bricking kernels and differences to genocide. Since there is no charging light when plugged in, it is still some catastrophic failure. Would RAM or video failure be enough to prevent the phone from charging? Or turn on the charge light?
Do you BONSAI?
Click to expand...
Click to collapse
I find it very very very very unlikely that the screen would do this..usually the screen is a separate component..In a pc for example ive had pc not turn on due to bad ram though...

gTen said:
I find it very very very very unlikely that the screen would do this..usually the screen is a separate component..In a pc for example ive had pc not turn on due to bad ram though...
Click to expand...
Click to collapse
Wasn't thinking the screen, I was thinking the video components on the circuit board due to LCD undervolting. But was def thinking dead RAM as a possibility.
Do you BONSAI?

With just Voltage Control my phone would hit 100 every blue moon. In conjunction with SetCPU on conservative it now idles fine at 100mhz and UV'd by 125. It seems to automatically revert to noop whenever I set it to bpq.

[Idea] Faster Charging

I noticed that in aosp roms, the battery charges faster. If we could hunt down the reason of this, we can implement this in touchwiz based roms.
Sent from my SPH-D700 using XDA App

Possibly they use less power when the phone is idle (ie less apps running in the background, maybe undervolting). Since they use less power sitting there, they would charge faster.

Doesn't our aosp rom still have touch wiz framework?
Sent from my SPH-D700 using Tapatalk

gtuansdiamm said:
Doesn't our aosp rom still have touch wiz framework?
Sent from my SPH-D700 using Tapatalk
Click to expand...
Click to collapse
He's talking about actual AOSP roms like cyanogenmod.
Texted while driving

Well Gingerbread in itself is more energy efficient..its one of the features of gingerbread...that and hummingbird optimizations help too..the faster it completes the process the faster it can go idle.

on related note, I'm wondering if it's possible to undervolt even more at say 200Mhz when the phone goes to sleep ??
just curious if it would even allow the phone to wake up, negative effects, etc. or 'might' it be worthwhile ?

gtuansdiamm said:
Doesn't our aosp rom still have touch wiz framework?
Sent from my SPH-D700 using Tapatalk
Click to expand...
Click to collapse
We don't have a real AOSP rom.
Sent from my Frozen Epic using XDA App

daddymikey1975 said:
on related note, I'm wondering if it's possible to undervolt even more at say 200Mhz when the phone goes to sleep ??
just curious if it would even allow the phone to wake up, negative effects, etc. or 'might' it be worthwhile ?
Click to expand...
Click to collapse
I had -125mV and when the battery got below 40% phone wouldn't wake up. So that will vary from phone to phone.

daddymikey1975 said:
on related note, I'm wondering if it's possible to undervolt even more at say 200Mhz when the phone goes to sleep ??
just curious if it would even allow the phone to wake up, negative effects, etc. or 'might' it be worthwhile ?
Click to expand...
Click to collapse
Not sure whether you meant "undervolt" or are talking about the processor speed being throttled back... two different things (but your units for the 200 are wrong for undervolting). Are you talking about undervolting or CPU speed?

beejmeister said:
Not sure whether you meant "undervolt" or are talking about the processor speed being throttled back... two different things (but your units for the 200 are wrong for undervolting). Are you talking about undervolting or CPU speed?
Click to expand...
Click to collapse
I believe he is talking about both, undervolting at each clockspeed. I do this with Voltage Control.
Do you BONSAI?

marcusant said:
I noticed that in aosp roms, the battery charges faster. If we could hunt down the reason of this, we can implement this in touchwiz based roms.
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
this has already been done, nubecoder did it with an older bonsai kernal. works great, unfortunately no one else wants to do it. battery charges much faster and fully to 100% instead of 97%.
I'm not using the kernal now because it doesn't work with cpu spy and it doesn't work with wifi tether. but the info is there on how to do it and should be easy to do to other kernals. Unfortunately i don't have the knowledge to be able to do something like that.

beejmeister said:
Not sure whether you meant "undervolt" or are talking about the processor speed being throttled back... two different things (but your units for the 200 are wrong for undervolting). Are you talking about undervolting or CPU speed?
Click to expand...
Click to collapse
I was talking about both, throttling back the CPU when sleeping AND undervolting the 200mhz step at the same time while sleeping to conserve battery more, thereby 'hoping' for a quicker charge.
just an idea.

[Discussion] Does Undervolting saves battery life??

I have been following Galaxsih kernel thread and there was a discussion whether undervolt saves battery or not.
Some people believe it does not save battery life.
Originally Posted by bedalus
Miscellaneous
[Q] You claim you cannot increase battery life using UV beyond 2%. Justify yourself!
[A] When the processor is in use (i.e. not asleep or idle) UV does save a tiny amount of power. I tested with the most extreme UV my phone could handle. With a high performance governor, e.g. smartassv2, extreme UV would reduce CPU drain by 13%, or about 7 mA. With a governor that keeps the CPU frequency low, CPU drain would be reduced by about 18%, or 4.6 mA (weighted - see the spreadsheet starting cell H88).
Remember, these savings are limited to the processor, and only when it is active. For most users, this will mean the screen is on. For comparison, the screen on minimum brightness displaying black uses 9mA. On max brightness, displaying white, it uses 690mA. Let us assume some median value, ~350 mA.
A saving of 4.6 mA out of at least 350 mA (screen) plus 20 mA (CPU)
= 1.2%
A saving of 7 mA out of at least 350 mA (screen) plus 50 mA (CPU)
= 1.8%
So, regardless of your choice of governor, even with extreme undervolting, you are not going to be able to increase your battery life by more than 2%.
But eric-filth and some other people including my self claim that it saves battery.
i have tested it as eric suggested (run antutu 10 times with and without UV from 100% battery.)
without undervolt i have lost 10% whereas with UV i only lost 6%
so people please share your experiences with UV.
Do you think it helps in terms of saving battery?

It isn't made to save battery life... UV provides less voltage so that there is less heat and more stability.
Sent from my GT-I9300 using xda premium

b-eock said:
It isn't made to save battery life... UV provides less voltage so that there is less heat and more stability.
Sent from my GT-I9300 using xda premium
Click to expand...
Click to collapse
Does that mean UV does not save battery at all?

It is such a miniscule amount that the user wont be able to tell. If you took accurate numbers from the system, maybe you could see it.
Sent from my GT-I9300 using xda premium

I agree. Uv is mainly designed to limit heating while oc.
But it's like religion, people convinced that it saves battery noticeably will always think that.
So it doesn't matter in fact. But as chips are not the same and have flaws, uv can lead to instability. That's why kernel devs don't want bug report if kernel is uv.
You'll notice that none of kernel devs use uv themselves.

b-eock said:
It isn't made to save battery life... UV provides less voltage so that there is less heat and more stability.
Sent from my GT-I9300 using xda premium
Click to expand...
Click to collapse
Epic lol on stability! The main problem with UV is it can cause INstabaility!
About heating I'd rather trust some data about it, but it's quite hard to test actually...
About battery? Completely agree that who "see" it saving battery will keep it like this... Epic placebo, luck on the chip or maybe Jesús crist blowing into their battery but if it works for them let's keep it plane...
Anyway, just chating makes no sense to me on this unless some PROPER tests are done, and sorry not to agree on using Antutu for testing but it looks like a bs of s test to me!
Enviado desde mi GT-I9300 usando Tapatalk 2

While it can cause instability. So can OVERVOLTING, so both OV and UV can cause instability. There is a sweet spot for every phone... So i dont know why you are LOL'ing...
You obviously haven't compiled kernels, debugged and tested them, know about the voltages with CPU, or ever talked to a kernel dev. UV can help stability, too much will hurt stability. Same as OV. It can help with the right amount, and hurt with too much.
Sent from my GT-I9300 using xda premium

b-eock said:
While it can cause instability. So can OVERVOLTING, so both OV and UV can cause instability. There is a sweet spot for every phone... So i dont know why you are LOL'ing...
You obviously haven't compiled kernels, debugged and tested them, know about the voltages with CPU, or ever talked to a kernel dev. UV can help stability, too much will hurt stability. Same as OV. It can help with the right amount, and hurt with too much.
Sent from my GT-I9300 using xda premium
Click to expand...
Click to collapse
Not nice to make wrong assumptions about what had I and what hadn't I done m8
Ov is bs most of the times for same reason UV is, go read again, I never even mentioned OV any place...
Right voltage is right voltage, meaning it's in the interval of correct function of the cpu. No more, no less. I never said anything different so sorry but you did a nice mistake there
Any way, as said on the other thread I'm out of discussing nonsense about UV, people trusting it will keep doing it as, for whatever, they feel it works. And I KNOW it doesn't work to save any juice, at least ofc, for me. And keeping device cool, well, that makes more sense but I've not seen a single testing about that, and I bet none of us can feel even a 10% less heat or whatever it is just by using device...
Edit: about instability, try undervolting by 150 and let's see if it boots, then try IV by 150, **** on both, so then try stock or nearly stock voltages... for me my friend that is instability when touching voltages
Enviado desde mi GT-I9300 usando Tapatalk 2

I used to be on Franco r20 (no UV) and then I switch to Siyah r1.7rc1 with UV and OC to 1.6.
My phone now last 12 hours more compare to 18 hours before. I dunno if it is the UV or some different in the kernel parameters/features.
Needless to say I'm happy with Siyah.

Edit-I am mot going to argue. I was provong a point and was right. Get over it. Conversation over.
Just so you know. My old Cappy could run at 1.92 GHz with -150mv and be stable. So that invalidates your statement...
Sent from my GT-I9300 using xda premium

b-eock said:
Edit-I am mot going to argue. I was provong a point and was right. Get over it. Conversation over.
Just so you know. My old Cappy could run at 1.92 GHz with -150mv and be stable. So that invalidates your statement...
Sent from my GT-I9300 using xda premium
Click to expand...
Click to collapse
Lucky there, enjoy it you really love this don't u? Lol anyway, enjoy your uv kinda miss sensation times actually...
Enviado desde mi GT-I9300 usando Tapatalk 2

I say keep it all stock and don't mess around with the voltage. Just going to make things more worse!

Safe Undervolting

Hi, I've lowered all the figures by 100mv, but I notice no difference in my battery life. Is it safe to lower the figures more?
Sent from my Nexus 7 using xda premium

Define what you mean by "safe".
Higher core voltages are used at higher clock rates in order to preserve logic margin in the face of more power supply noise and tighter timing. So, undervolting by definition means you are giving up margin.
Whether your SoC happens to have a worst-case timing path which is "fast" or "slow" relative to other devices cannot be deduced by anyone here on XDA or even at Nvidia. About the best you can hope for is some "feel good reports" about what others do with undervolting and completely undisciplined "testing". But even that provides no information about your individual chip.
good luck

Thanks for your reply. By "safe" I mean without damaging my device. And yes, it would be interesting to hear some undervolting stories. I'd quite like to extend my battery life. Cheers!
Sent from my Nexus 7 using xda premium

I've been using my nexus 7 runing a AOKP pub build by mrRobinson and franco's r47 kernel. i've undervolted the entire board by 100mv it is runing pretty solid without any noticible lag or instability. Yet every chip is diferent and can or cannot this margin you'll have to test for your self. Just leave the option 'set on boot' unticked untill your sure that your device is capable of using those kind of voltages. And don't use very large steps. Just like overclocking in fact! Try it - it runs - get a little bit lower. If it crashes you shoukd be able to reboot the nexus and the settings you've changed reseted
Sent from my Nexus 7 using Tapatalk 2

antmasi said:
I've been using my nexus 7 runing a AOKP pub build by mrRobinson and franco's r47 kernel. i've undervolted the entire board by 100mv it is runing pretty solid without any noticible lag or instability. Yet every chip is diferent and can or cannot this margin you'll have to test for your self. Just leave the option 'set on boot' unticked untill your sure that your device is capable of using those kind of voltages. And don't use very large steps. Just like overclocking in fact! Try it - it runs - get a little bit lower. If it crashes you shoukd be able to reboot the nexus and the settings you've changed reseted
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
Thanks! Have you noticed any improvement in battery life?
Sent from my Nexus 7 using xda premium

Been testing for 2 days now! Battery seems a little bit better yet maybe placebo! But i feel it does not get has hot as runing stock voltages! It was the main reason i did the undervolt!
Sent from my Nexus 7 using Tapatalk 2

antmasi said:
Been testing for 2 days now! Battery seems a little bit better yet maybe placebo! But i feel it does not get has hot as runing stock voltages! It was the main reason i did the undervolt!
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
Placebo
Sent from my Nexus 7 using XDA Premium HD app

For what i've read that's the truth but if the frequencies set for the soc are getting less power shoudn't it draw less power from battery? 100mv its almost 10% of the stock voltages!
Sent from my Nexus 7 using Tapatalk 2

antmasi said:
For what i've read that's the truth but if the frequencies set for the soc are getting less power shoudn't it draw less power from battery? 100mv its almost 10% of the stock voltages!
Click to expand...
Click to collapse
For the SoC, whether it's leakage (V^2/R) or dynamic power dissipation (f*C*V^2), yes, you might expect let's say (0.9^2) = 81% battery use at the same operating frequencies.
OTOH, if 75% of the power drain normally is used by the LCD backlight (for instance in a "reading web pages" use case), then reducing the supply voltage will get you only 1/4 of that 20% savings - about a 5% improvement - because the power is being dissipated elsewhere. (Display, DRAM, 3G radio, WiFi radio, etc)

I agree with what you've pointed! In fact i've just taken out the undervolt because Inhad a reboot under heavy multitasking (torrent download, xbmc opened, chrome also downloading a smal file) i'm not certain that it was caused by the uv but it's possible. The Nexus started to lag and then froze completly! From time to tima i've the need of heavy multitask and it wasn't up to the task!
Sent from my Nexus 7 using Tapatalk 2