Database Develop

[HACK] Overclocking/Undervolting kernels with Voltage Control support

Hello,
I'm the author of Voltage Control, an application for Galaxy S series to control OC/UV kernels. I don't personally own a Nexus S (and I cant say I will, unless someone want to Nexus S donate one for me ;p).
Voltage Control Lite 4.00 on Android Market!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I know there are many apps to control OC, but I dont know any doing UV work.
If anybody is interested in making UV kernel for Nexus S there are some working kernels for SGS (given the hardware similarities some knowledge may be taken from current solutions).
Authors of most OC/UV code are raspdeep and Unhelpful, heres the topic: http://forum.xda-developers.com/showthread.php?t=822027 and second: http://forum.xda-developers.com/showthread.php?t=762171
If you are interested in creating UV kernel working with Voltage Control, I'll give brief explanation how VC works, and how are things done on SGS.
My application communicates with kernel via sysfs interfaces via cat and echo:
mandatory:
Code:
/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state // to read all states
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq // may be obsolete, didnt make a decision yet
Code:
/sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
key in UV procedure, it represents undervolt for each frequency from highest to lowest; "25 25 50 50 100" means UV highest freq by 25, and lowest by 100
providing additional functionality:
Code:
/sys/devices/system/cpu/cpu0/cpufreq/frequency_voltage_table
Containing all frequencies and corresponding voltages, format:
FREQ STOCK CURRENT
Code:
1120000 1300 1300
1000000 1300 1300
This is useful for determining stock voltages used by the device, because they are needed in voltage calculation. Stock values are hardcoded, but If you want to change them I suggest to implement this table, to let user know at exactly what voltage his device is running.
Third column is obsolete, since VC calculates current (stock-uv) voltage itself might be removed in the future.
Code:
/sys/devices/system/cpu/cpu0/cpufreq/states_enabled_table
This is table where we store enabled ("1") and disabled ("0") state for each frequency;
"0 1 1 0 1" means we disabled highest frequency and second to lowest.
This is useful when kernel developer wants to produce ONE kernel for all OC lovers.
This means there could be one kernel supporting OC frequencies up to 1600Mhz (lets say 1600,1500,1400,1300,1200,1120), and user could choose which ones he wants to use (eg 1400 and 1120, disabling the rest).
I'm aware that Nexus S will receive tremendous attention from developers so I believe that someone might actually come with better implementation (single table consisting of all information needed by VC?)of this mess.
Best idea would be to make one table for all information, so it can be easily parsed.
Current version of app is 4.0 beta, which is a complete rewrite.
I'm open for ideas, suggestions regarding additional features.
Happy OCing.

Thanks xan for this invitation
Unhelpful also played a big part with the initial code to load dynamically frequencies and voltages using a sysfs interface.
BTW, your app source is welcome on project-voodoo github !
I know several people motivated to contribute, it would be a place to start.

Right, Unhelpful, adding topic to OP.
Yes, this needs to be open-sourced.
No date yet, because there are monsters inside.
The thing that struck me now, is why is all of that so complicated?
I think I like single-table idea more and more.

ill volunteer to help.

Very exciting to see some of the best dev names from the SGS community showing interest in the Nexus S. Many goog things to come for us if they remain interested...

So when are we gonna see a 1.2GHz Voodoo OC/UV kernel

My phone recieves a noticeable speed increase with the voodoo kernel for Nexus S with max and min set to 1000 with performance governor Can't wait for a super optimized kernel OC/UV!

looking forward to a UV kernel to extend battery life.

jroid said:
My phone recieves a noticeable speed increase with the voodoo kernel for Nexus S with max and min set to 1000 with performance governor Can't wait for a super optimized kernel OC/UV!
Click to expand...
Click to collapse
Anything on battery?
defysword said:
looking forward to a UV kernel to extend battery life.
Click to expand...
Click to collapse
+1

why is no one compiling a kernel supporting xans app? i really loved it on my galaxy s and when i saw this threat i was hoping for a supported kernel for my nexus s. it really can make oc more stable if u r patient enough to test the best setzings for ur phone
Sent from my Nexus S using Tapatalk

Can't wait for this too. Xan's app is really good on SGS.

shrooms90 said:
why is no one compiling a kernel supporting xans app? i really loved it on my galaxy s and when i saw this threat i was hoping for a supported kernel for my nexus s. it really can make oc more stable if u r patient enough to test the best setzings for ur phone
Sent from my Nexus S using Tapatalk
Click to expand...
Click to collapse
This died the 22nd of December, I got my Nexus S around that time, kept it stock while on vacation over the holidays, missed out there.
I *may* check this out, don't want to turn into Patches....
But I could continue to build Honity stable for Will, but others run lower than he does.
Instead of stock + UV build it would be only 1.
And Honity14 could be the UVOC some want.
Problem in that is that I take a risk of people not understanding the "use at your own risk" part involved.
Thanks for bumping this thread, didn't know xan had this.
Sent from my Nexus S

morfic said:
This died the 22nd of December, I got my Nexus S around that time, kept it stock while on vacation over the holidays, missed out there.
I *may* check this out, don't want to turn into Patches....
But I could continue to build Honity stable for Will, but others run lower than he does.
Instead of stock + UV build it would be only 1.
And Honity14 could be the UVOC some want.
Problem in that is that I take a risk of people not understanding the "use at your own risk" part involved.
Thanks for bumping this thread, didn't know xan had this.
Sent from my Nexus S
Click to expand...
Click to collapse
sounds good. i like honity kernel but for my phone it needs a little fine tuning.
i think people would understand "use at ur own risk" imo most people understood it on the sgs forum.
so i really would love to see honity14 with uv options
Sent from my Nexus S using Tapatalk

Is there any progress?

xan said:
I'm open for ideas, suggestions regarding additional features.
Happy OCing.
Click to expand...
Click to collapse
Hi. great stuff here. would this app work (or made to work) using snq-'s undervolting via sysfs here.
I use a kernel with the above patch enabled and my ROM users would love to be able to do this using an app like this.
Thanks!

pongster said:
Hi. great stuff here. would this app work (or made to work) using snq-'s undervolting via sysfs here.
I use a kernel with the above patch enabled and my ROM users would love to be able to do this using an app like this.
Thanks!
Click to expand...
Click to collapse
Im a noob when it comes to kernel developping, but i hope this will help u:
From what i understood this app undervolts using following command:
echo "0,0,50,100,0...." /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
Where the numbers stand for the amount of undervolting in mV for each freq. (I think it is from lowest to highest but im not sure. If u set the values at boot it just writes a startup script in /system/etc/init.d/
Sent from my Nexus S using Tapatalk

Fantastic,
The nexus s dev community is definitely growing now
JD
Sent from my Google Nexus Magic Wand S

JupiterDroid said:
Fantastic,
The nexus s dev community is definitely growing now
JD
Sent from my Google Nexus Magic Wand S
Click to expand...
Click to collapse
wtf? fancy seeing you here

Stea1thmode said:
wtf? fancy seeing you here
Click to expand...
Click to collapse
WTH young man, did you get lost

Just thought that I'd mention this.
I develop a kernel for the Captivate for CM7. Our cm kernel is based off Nexus S code, so anything that works under it will work under your kernels as well (probably). I've implemented this successfully under my kernel with no real problems.
Just add a sysfs interface to the cpufreq driver to store the uv amount, then subtract that amount * 1000 from arm_volt before feeding it into the regulator.
Sources are here --> https://github.com/TheEscapistxda/CM7-OCUV
PS I apologize for my terrible commenting.

[JB]Result of Benchmark Comparison with different ROM&Kernels

this is my first thread in xda. sorry if i break any rules. and plz tell me if i did.
============================================================
Hello committee! I just registered here a few days ago and find it a really nice place. i found a lot of useful infos and learned skills here. enjoyed every second reading the posts.
i just spend the afternoon testing with some different kernels and ROMs. trying to figure out which one should i choose for daily use. i know it would be a long term testing to get a conclusion but this is a start anyway.
i'm posting my result here hoping could do a little contribution to this committee. and PLEASE share your ideas with me too!
============================================================
I used the app AnTuTu Benchmark on my Nexus S. dunno if it's the best benchmarking app but i think as long as i keep all the other settings the same. the result still tells some truth.
The results below ONLY show the performance of roms and kernels at BENCHMARKING. it does NOT say anything about battery life, usability or stability.
View attachment 1265857
=======================UPDATE===============================
AOKP seems not working properly with AirKernel. trying to figure out why. anyone can help?
*Air186B65f = AirKernel #186 BlueColor with 65fps
*Air186V = AirKernel #186 VoodooColor without 65fps
(both the above are High-BigMem versions.)
*marOTA4.2= marmiteKernel v4.2 for stockOTA ROM
*mar4.2 = marmiteKernel v4.2 for Custom ROMs
*bfq is not currently available on marmiteKernel v4.2 so i only tested deadline. dunno if it's a proper choice.
*Adroxd = Androxide 3.1.0
*NotPass = benchmarking was interrupted by force close of the app.
some conclusions:
1. ROOT does NOT affect the performance on stock ROMs.
2. performance does NOT do better at benchmarking, as it's supposed to, than some other governers.
3. NotPass does NOT happen every time with the same settings. i.e. i tested 2 times at 1.4GHz with smartassV2 and bfq on stock ROM. the first time it gave an result of 4090. but the 2nd time it force closed.
4. schedulers seem to be not affecting benchmarks on a big scale.
5. The result shows stock ROM with custom kernels DOES better performance than custom ROMs. (I like things to be stock. it makes me feel safe. But at the same time i prefer those mods in custom ROMs like the volume rocker wake-up and advanced power menus.)
6. I love xda-developers.com :laugh:

New benchmark expert arrived!
Welcome!
Edit: aha...not in-progress like bedalus:/
Sent from my Nexus S using xda app-developers app

Since you are new to this let me say something that most users are unaware of: the governor is absolutely irrelephant. The CPU will always be at 100%, otherwise it's not a true benchmark, thus rendering the delay to reach such % (basically what a governor does) a parasite variable.
The I/O scheduler performance is also tricky to measure as some are better in sequential operations, some are not.
So if you want to test ROMs & kernels (which makes much more sense, not I/O schedulers and governors), then here are a few tips:
More ROMs (make sure to include CM as it has many small code optimizations).
More kernels.
Drop the governor column and do everything in performance (this will force the max CPU frequency and eliminate the aforementioned parasite variable).
Choose one I/O scheduler and use it for every kernel (homogeneity).
Don't do OC.
Use more benchmarks (CF-Bench, Sunspider, GLBenchmark).
Run at least 3 times and note down the average result.

ioplkj13 said:
New benchmark expert arrived!
Welcome!
Edit: aha...not in-progress like bedalus:/
Sent from my Nexus S using xda app-developers app
Click to expand...
Click to collapse
LOL no i'm not a benchmark expert, yet. ;D but thanks for the advise. i think in-progress makes ppl excited and helps me to do the work better. just like knzo's post!
knzo said:
Since you are new to this let me say something that most users are unaware of: the governor is absolutely irrelephant. The CPU will always be at 100%, otherwise it's not a true benchmark, thus rendering the delay to reach such % (basically what a governor does) a parasite variable.
The I/O scheduler performance is also tricky to measure as some are better in sequential operations, some are not.
So if you want to test ROMs & kernels (which makes much more sense, not I/O schedulers and governors), then here are a few tips:
More ROMs (make sure to include CM as it has many small code optimizations).
More kernels.
Drop the governor column and do everything in performance (this will force the max CPU frequency and eliminate the aforementioned parasite variable).
Choose one I/O scheduler and use it for every kernel (homogeneity).
Don't do OC.
Use more benchmarks (CF-Bench, Sunspider, GLBenchmark).
Run at least 3 times and note down the average result.
Click to expand...
Click to collapse
these are very helpful! i'll take the advise and make my test better.
but i don't think i'll do A LOT ROMs and kernels. since i'm just testing those ROMs and kernels which i might be using for daily. but i WELCOME all other guys here to post their results! :fingers-crossed:
again, many thanks to your help!

So the best rom+kernel is the stock+air kernel?

We need more numbers. A benchmark thread with nearly only conclusions is just asking people to believe you without any proof. Not gonna happen in a place full of skeptics.
Knzo suggestions are very good too. You need more homogeneity in your benchmarks. Being all over the place only adds variables in the equation that favor one kernel or the other. And more tests. Pretty much just follow all what he said.
knzo said:
Since you are new to this let me say something that most users are unaware of: the governor is absolutely irrelephant
Click to expand...
Click to collapse
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Irrelevant*

polobunny said:
Irrelevant*
Click to expand...
Click to collapse
You don't really think I'd write irrelephant unintentionally right? I'm meme-aware! ;p

knzo said:
You don't really think I'd write irrelephant unintentionally right? I'm meme-aware! ;p
Click to expand...
Click to collapse
Haha! You got me there. I kinda knew of your meme ways, but that was some good trolling right there.

•Run at least 3 times and note down the average result.
Click to expand...
Click to collapse
Try to make the conditions the same for each run. For example, restart the phone and leave idle for 3 minutes, etc.

Andrew1998 said:
So the best rom+kernel is the stock+air kernel?
Click to expand...
Click to collapse
remember there's nothing called "best". as i said above the result only shows performance at benchmarking. as we know good benchmark score may result in poor battery life so it's not recommended for daily use.
if you could help this work it's much appreciated!
maybe you just do a benchmark (takes only 3 mintes) and post your rom and kernel with the score.
best wishes.

vikingsail said:
this is my first thread in xda. sorry if i break any rules. and plz tell me if i did.
Click to expand...
Click to collapse
Well since you asked nicely, you did post in the wrong section.
Thank you for the data, and there have been some good suggestions about tweaking the method.

Stock Rom.. air kernel #186..
Sent from my Nexus S

siddhesh.raikar said:
View attachment 1267462
Stock Rom.. air kernel #186..
Sent from my Nexus S
Click to expand...
Click to collapse
that is very impressive! any tweaks?

polobunny said:
We need more numbers. A benchmark thread with nearly only conclusions is just asking people to believe you without any proof. Not gonna happen in a place full of skeptics.
Knzo suggestions are very good too. You need more homogeneity in your benchmarks. Being all over the place only adds variables in the equation that favor one kernel or the other. And more tests. Pretty much just follow all what he said.
yes that's indeed what we need. i wish more ppl could take part in this.
and i'm trying to take more homogeneity into my testing. thanks for the advise!
Irrelevant*
Click to expand...
Click to collapse
sysadmn said:
Try to make the conditions the same for each run. For example, restart the phone and leave idle for 3 minutes, etc.
Click to expand...
Click to collapse
very funny...

siddhesh.raikar said:
View attachment 1267462
Stock Rom.. air kernel #186..
Sent from my Nexus S
Click to expand...
Click to collapse
Haha you over clocked to 1.4ghz. Here is mine.
Sent from my Nexus S using xda app-developers app

Good luck!

..

Kernels battery benchmarks

Hello everyone...i know we all share the same question...which kernel is better in terms of battery...so i decide (I had done this before but an admin lock the threat) but i decide to do it again..cause i really want this anwer, at least a part of it, to be answered...so i decide to stick with one rom, difficult don't try this, and simply flash all available kernels there is out there...run AnTuTu battery benchmark and compare the results
Im not so good with words so here it goes...
Rom Aokp Preview...I know all you start saying that this is a preview rom i should test this with a more stable rom...but all i want is to test the kernel it self...not the rom...so none or if a bit of rom bugs/drains will cause this test to fail cause i didnt use the phone at all, the whole 2 hours of the benchmark...
All my apps..i have at least Android is upgrating said 150 apps Titanium sais 98 without the system...i want to see the kernel working at a normal setup...maybe its nothing but who knows...
Wifi on 3G off...as i said i want this to be run at normal usage..we all have wifi open if not 100% 85% of our usage...
And for the end...i left all kernel settings pure default...i dont use FKU,Fauxclock,Semamanager or not even Trickster...if a dev as for example @morfic wants Trinity to work 2cores its fine by me...I didnt change nothing no UV no OC no UC no nothing....
The test needs 100% battery to run...of course..and a straight 2H and some minutes depenting on kernel to run from 100% to 73% to 46% and finaly to 19% by mesuring the time it took it to drain all this juice we found the drain per minute that we need to compare our kernels...
Test also mesures battery temp..so we mesure average battery temp...i have cpu temp widget but i can't stare the screen all this hours to check the temp when a sertane percedance is reached...also...for those who wanter why i haven't test francos yet...i also said this to @franciscofranco on google+ at 85%+- of the test i notice that the cpu gets really hot..im talking about 86C so the test stops..i manage to test it once by leaving my phone to my floor that cold but i mistakanly forgot 3G on and the test finish on 40minutes!
Anyway..here is my spreadsheet feel free to comment if i made something wrong specially on sums..and on the attachments i will add 3 pics of each kernel showing the end screen of the test,the rating of the test and the drain line on settings...
26/09/13:I decide to enable UnderVolt to the kernels from here and on...Matrix 11 just like franco...and semaphone for some strange reason don't have a proper thermal throtle...at 86C the test just stops...so im hopping i can keep it below that temp to be able to run the test!!
Thanks and remember this is just benchmark..feel free to test kernels yourself to see which one fits you best...and sorry that i kill your language!!
Next kernel: Bricked
21/09/13 Base rom changed to PSX....all kernels will be re-tested...sorry for the delay...
22/09/13:Finish benchmark for Faux123 26m
23/09/13:Finish benchmark for Trinity T4h
24/09/13:Finish benchmark for Stock 4.3
25/09/13:Finish benchmark for Franco 184*Retest needed
26/09/13:Finish benchmark for Matrix 11**-112mV enabled
26/09/13:Finish benchmark for Sema 1.6.5**-100mV enabled
27/09/13:Finish benchmark for AK 25+
28/09/13:Finish benchmark for NEO 12**-112mV enabled
28/09/13:Finish benchmark for Hells-core B38**-125mV enabled
29/09/13:Finish benchmark for Franco r184**-125mV enabled
30/09/13:Finish benchmark for Reborn90 r184**-125mV enabled
1/10/13:Finish benchmark for Bricked 20/9**-125mV enabled
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

Wow I can already tell this is going to be very useful and answer a lot of questions, thanks in advance for this!!

a thought maybe.. how about adding the default nexus 4 android kernel to the graph? it would make the comparison more interesting

I think this is very utility, wating for franco kernel.

Wow OP.. By any chance after these test could you use the best kernel out of these test and also do a analysis on the radios of mako. I think 3g test can predict the difference on battery drain using each one of them.

simms22 said:
a thought maybe.. how about adding the default nexus 4 android kernel to the graph? it would make the comparison more interesting
Click to expand...
Click to collapse
I could use the stock 4.3 kernel to check the difference...its a good advice....
arjunv said:
Wow OP.. By any chance after these test could you use the best kernel out of these test and also do a analysis on the radios of mako. I think 3g test can predict the difference on battery drain using each one of them.
Click to expand...
Click to collapse
With 3G open the results are gonna hurt many devs...as i said the only success test with franco kernel with 3G open but not in use cause of open wifi...the test from 2.04hours of faux it goes to 40minutes with franco....im using hybrid .34 modem right now....even than im not be able to get any 4G signal... :/
Also thanks for you kind words....i thought by now the threat cause be locked by a admin like the 1st one!!

Nice thread! Will solve some general problems regarding kernels maybe.

3mperror said:
Nice thread! Will solve some general problems regarding kernels maybe.
Click to expand...
Click to collapse
As i said they are just benchmarks...its gives an idea of what each kernel can do...at least of a non stop benchmarking point of view...
I finished semaphones benchmark but after the reboot i saw that from 18% the battery goes to 36% so there is something wrong with the batterystat.bin file...so i have to redo this benchmark so i can be as accurade as i can!!!

Very usefull thread,good job
Sent from my Nexus 4 using Tapatalk 4

Correct bench of Semaphone 1.6.5 next kernel again..franco r185!!!

intresting.....
waiting for Matr1x results

Some one out there have been doing the exact same thing over the past week with me then ! hahaha - I have Carbon Rom as a base, I have had it on Franco, Faux, Sema & Matrix - All same setup, same apps, same usage - And the best results I have had so far is Carbon + Matrix Kernel. Looking forward for your experience.

Ensifolk said:
Some one out there have been doing the exact same thing over the past week with me then ! hahaha - I have Carbon Rom as a base, I have had it on Franco, Faux, Sema & Matrix - All same setup, same apps, same usage - And the best results I have had so far is Carbon + Matrix Kernel. Looking forward for your experience.
Click to expand...
Click to collapse
you didnt do trinity kernel, id consider it one of the major kernel :crying:
just teasing
did you do the stock kernel, to use as a base?

simms22 said:
you didnt do trinity kernel, id consider it one of the major kernel :crying:
just teasing
did you do the stock kernel, to use as a base?
Click to expand...
Click to collapse
Simms mate! Hehehe, first, love your pics on twitter! Second, I am still in the testing process - Gonna flash Trinity on a day I know Im gonna be on full wifi and free on time - I want the test to remain objective and under the same past conditions.

S2 has/had a similar thread. Great!

Excellent thread, I cannot wait till you finish your table, and btw, thanks for doing this man, big big help for all of us
Sent from my Nexus 4 using xda app-developers app

Thanks for all your kind words!!!

Is the antutu battery tester only causing heavy load? Because that would ignore kernel's idle drain
Also, I'd chose always the most recent kernel version to test. hellcore is at b37 right now (maybe just a typo?)

ccab said:
Is the antutu battery tester only causing heavy load? Because that would ignore kernel's idle drain
Also, I'd chose always the most recent kernel version to test. hellcore is at b37 right now (maybe just a typo?)
Click to expand...
Click to collapse
Good question !
Sent from my Nexus 4 using xda app-developers app

This is a very use full piece of work, thank you for your time, and I look forward to seeing how matrix does. one point to note as well as the comments about idle, is that different kernels behave differently sometimes depending on the ROM that they are paired with, so possibly repeating the test with a cyanogen based ROM and some 3rd ROM for all of the kernels before taking an average might be an interesting test. But of course it is up to you, I don't know how much time you have :thumbup:
Sent from my Rooted NEXUS 4

Nexus 5 Undervolting thread

I found this thread very useful on the N4 forums, so here it is for the Nexus 5.
First, what is undervolting?
No two CPUs are made equally, every one is slightly different. This means they each need a different minimum voltage to run completely stable, so manufacturers set it high enough so that every chip can run without needing a voltage tailored to that specific chip. But this means that most devices can have their voltages lowered, and still run 100% stable
What are the benefits of undervolting?
In my experience, heat reduction is the main benefit. However, this heat reduction has implications elsewhere; for instance it means the thermal throttling will kick in later, so there is less of a performance drop. Also, less power is wasted to heat, meaning marginal gains in battery life. If you cannot run higher frequencies, i.e. over 2.26GHz, undervolting/overvolting these frequencies may help.
Any disadvantages?
Not really - you may experience reboots and instability, but that means you need to raise the voltages. Also, make sure you don't check set on boot until you know the voltages are stable, but if you have any problems you can flash the stock kernel, or in worst case wipe the data from a recovery.
How do I undervolt?
Many CPU apps are available to change the voltages, but personally I use Trickster Mod (donate). Just slowly decrease your voltages, small amounts at a time, and set them on boot when you are happy they are stable.
If you want to really want to get your voltages perfect, you can set the min/max frequency to one you want to modify, and edit each frequency to perfection. To save time, I'd recommend starting with the highly used frequencies - many apps can tell you which your device uses most often.
CPU Binning
I know on the nexus 4 the cpu bin was related to the amount users could undervolt, and Im sure the case is still the same, so heres how you can find out your CPU bin: http://forum.xda-developers.com/showthread.php?t=2515593 It would be useful to include your CPU bin in your post.
Here are my initial voltages, running ElementalX v0.7, CPU bin 3 and PSX - please, feel free to share yours (and your knowledge);
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Rules of the thread
Be nice to each other, use search if you have a question, and don't flame noobs for no reason.
It would be helpful to include your CPU bin and kernel in your post.
Also, if I have made any errors in the OP or you feel something should be added, quote this (so I get notified) and tell me, I'm sure theres a lot more information I could include!

Reserved

PVS3 -50 Stable

uh60james said:
What's your CPU bin?
Click to expand...
Click to collapse
Just added to the op, I have a 3, which I think is about in the middle? I haven't had a proper look at the thread yet to find out
Sent from my Nexus 5 using Tapatalk

Tom540 said:
I have a 3, which I think is about in the middle?
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
I have a 3 too. So far sitting stable at a global -62.5 undervolt the past few days. Tried -75 a few times and got reboots when turning the screen on.

AndrasLOHF said:
I have a 3 too. So far sitting stable at a global -62.5 undervolt the past few days. Tried -75 a few times and got reboots when turning the screen on.
Click to expand...
Click to collapse
Same has just happened to me too, so I'll bump them up to -62.5, although I think I should be able to keep the lower CPU clocks at lower voltages as I'm sure the higher ones are used when turning on the screen
Sent from my Nexus 5 using Tapatalk

I'm running franco r14 and got two almost immediate reboots on your settings. Gonna go a little easier. I have no experience doing this, so it's still a bit confusing.

can probably go a bit easier on the higher clocks, my settings are -75 mv below 1.8 ghz and -50 above. Just played some deer hunter 2014 and seems to be fine. No reboots so farr! My bin is 3 as well. Running stock rom with faux003b6 kernel

I have a bin of 3 as well. I've only been brave enough to go -37.5 on Fauxs latest beta kernel
Sent from the jaws of my Hammerhead!

Got a CPU bin of 2. I went for -50 undervolt for all frequencies on Faux kernel 002 a few days ago, no reboots so far. Haven't tried -62.5 but -75 was too much, so I'll stick with -50.

I was a little bummed when I found out I had bin 2, but I've been running -75mv no problem for the past few days on bricked kernel
Sent from my Nexus 5 using xda app-developers app

You guys are lucky. My phone has bin of 1, could only uv 50mv on high frequency and 75mv on the low end, and I have higher default voltage to begin with.
---------- Post added at 01:33 AM ---------- Previous post was at 01:29 AM ----------
So far I believe the best app to test UV stability is Antutu Benchmark, I could pass StabilityTest no problem but Antutu always FC when I UV bit too hard.

Spunky_Monkey said:
I was a little bummed when I found out I had bin 2, but I've been running -75mv no problem for the past few days on bricked kernel
Sent from my Nexus 5 using xda app-developers app
Click to expand...
Click to collapse
wow.. im have bin 3 and anything past -62 I get reboots... I think I got ripped of on on my cpu

gd6noob said:
wow.. im have bin 3 and anything past -62 I get reboots... I think I got ripped of on on my cpu
Click to expand...
Click to collapse
Exactly the same with me - I think I might be able to set the lower CPU clocks with voltages lower though, I just need a bit more time to test
Sent from my Nexus 5 using Tapatalk

I have a PVS 0 and I can undervolt - 100 without any lockups or reboot. Actually the device hasn't rebooted on me once ever. The only problem is it lacks CPU performance but the GPU works fine.
Sent from my Nexus 5 using Tapatalk

Tom540 said:
Exactly the same with me - I think I might be able to set the lower CPU clocks with voltages lower though, I just need a bit more time to test
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
Let me know what your findings are... im just too lazy to test all the configs..

gd6noob said:
wow.. im have bin 3 and anything past -62 I get reboots... I think I got ripped of on on my cpu
Click to expand...
Click to collapse
Bin 3 here, I've been running with - 75 since yesterday without problem... Maybe I'll go lower
Sent from my Nexus 5 using Tapatalk 2

PVS 2 running - 75 volts full speed. Deer hunter runs great so far. Might try - 100 after more testing.
Sent from my Nexus 5 using XDA Premium 4 mobile app

seems like pvs3 is NOT the best for UVing, its all accross the board, im on PVS2 and i think i can do -75 easily , i think im on -50 accross, using franco kernel r14

It might be helpful if everyone included the actual voltages as well, as some have reported starting with different voltages, and some kernels UV put of the box.
PVS 3, I'm running 712.5 @ 300MHz, and 962.5 @ 2.26GHz; check the screenshot in the OP for all voltages
Sent from my Nexus 5 using Tapatalk

[APP][ROOT][BB][Bricked]KControl - Kernel control app for msm/tegra3

KControl for msm/tegra3 devices​
Requirements?
Root.
Busybox. (For doing stuff faster on the shell than in java, zcat for example and module ops)​
Playstore Link, Screenshots, Features, etc...
​
Supported devices?
Tested, by myself, on:
Nexus 5 (hammerhead)
Nexus 4 (mako)
Nexus 7 (grouper/tilapia)
Nexus 7 (flo/deb)
HTC One X (endeavoru)
HTC One S (ville)
Theoretically this app should work fully on any msm/tegra3 device using my kernels features. Tegra3 will lack thermal configuration though.
Functionality on stock kernels or custom kernels without Bricked features will be quite limited. (Everything with *1 or *2 in the feature list won't work then)​
How can I make my kernel compatible?
http://bricked.de/kcontrol_compat.php​
Where to complain about errors/bugs? (I have no doubt there will be some)
Please use the Issuetracker for bugs/errors/feature wishes!
Issuetracker @ https://github.com/showp1984/KControl/issues​
Changelogs:
http://bricked.de/kcontrol_changelogs.php​

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

This is a really great app. I can absolutely recommend it.
Sent from my Nexus 7 using Tapatalk 4

any mirror?
i can not use play store

mesarabi said:
any mirror?
i can not use play store
Click to expand...
Click to collapse
Nope.
Currently the only way to get it is through Google Play.

Will this app support ART? On Nexus 7 2013 Wifi it doesn't work with ART, only works with Dalvik

Steyux said:
Will this app support ART? On Nexus 7 2013 Wifi it doesn't work with ART, only works with Dalvik
Click to expand...
Click to collapse
4.4.2 I presume?
Hadn't tested with that yet, but probably only requires a rebuild with the 4.4.2 sdk. Will look into that, thank you for the report.

@show-p1984
Is it the normal behavior of the apk to be able to change frequencies of your mp decision?
I was able to mess your kernel, ak, faux... In fact all kernel running customs decision or touch boost..
My habit was from other soft like faux or trickster...
Hope I'm understandable...

sgs505 said:
@show-p1984
Is it the normal behavior of the apk to be able to change frequencies of your mp decision?
I was able to mess your kernel, ak, faux... In fact all kernel running customs decision or touch boost..
My habit was from other soft like faux or trickster...
Hope I'm understandable...
Click to expand...
Click to collapse
Not entirely. If you meant: "Is it normal that one can change the boost frequencies of bricked's mpdecision with KControl?" - yes.
I am unsure though what you mean about ak and faux.
KControl will offer you modification options for everything it detects, regardless of the kernel used. This means that KControl still features some options on 3rd party kernels other than bricked, or even on stock kernel. (on stock roughly ~50%, on any other custom kernel than bricked it's highly dependent on the features merged into it, but it won't be less than stock )

show-p1984 said:
Not entirely. If you meant: "Is it normal that one can change the boost frequencies of bricked's mpdecision with KControl?" - yes.
I am unsure though what you mean about ak and faux.
KControl will offer you modification options for everything it detects, regardless of the kernel used. This means that KControl still features some options on 3rd party kernels other than bricked, or even on stock kernel. (on stock roughly ~50%, on any other custom kernel than bricked it's highly dependent on the features merged into it, but it won't be less than stock )
Click to expand...
Click to collapse
Here is the man...
I will try being more understandable
I was able to change the normal mpdecision behavior
I mean the noob I am was looking in the frequencies tab...
There I saw was I thought were strange value... Now I know that it was the normal behavior for the frequencies not to be always in the range I select
So when I was thinking I correct them in fact I was modifying the normal behavior
For example on the screen shot
The dummy me was trying to fix touch boost... Causing bad working
Also sometimes the frequencies tab can be populated with not only touch boost but thermal decision which I was thinking them to be artifacts and needed to be set"properly" again...
I was (still but won't) able to edit intelliplug behavior... Faux mpdecision ..
Am I clear ?! Hope so

sgs505 said:
Here is the man...
I will try being more understandable
I was able to change the normal mpdecision behavior
I mean the noob I am was looking in the frequencies tab...
There I saw was I thought were strange value... Now I know that it was the normal behavior for the frequencies not to be always in the range I select
So when I was thinking I correct them in fact I was modifying the normal behavior
For example on the screen shot
The dummy me was trying to fix touch boost... Causing bad working
Also sometimes the frequencies tab can be populated with not only touch boost but thermal decision which I was thinking them to be artifacts and needed to be set"properly" again...
I was (still but won't) able to edit intelliplug behavior... Faux mpdecision ..
Am I clear ?! Hope soView attachment 2526286
Click to expand...
Click to collapse
Ah now I got you. So you wanted to know if it's normal behavior that the app shows you the real frequencies currently in effect and not the one you set. Yes, that is normal. The app always shows you the frequency range your soc is currently running on with those 8 text labels. They are meant as a monitoring option. Touchboost and thermal decisions will ofc interfere with your min/max freq for their respective durations.

show-p1984 said:
Ah now I got you. So you wanted to know if it's normal behavior that the app shows you the real frequencies currently in effect and not the one you set. Yes, that is normal. The app always shows you the frequency range your soc is currently running on with those 8 text labels. They are meant as a monitoring option. Touchboost and thermal decisions will ofc interfere with your min/max freq for their respective durations.
Click to expand...
Click to collapse
Yes... U say it more clearly
Perhaps an advice in your apk could be nice for user coming from faux clock or trickster mod...
Cause in those apk... This messing action isn't possible

Does this app have the ability to check for the latest version of the bricked kernel for the device its installed on and download it?
Sent from my Nexus 7 2013 using Tapatalk

lmulli said:
Does this app have the ability to check for the latest version of the bricked kernel for the device its installed on and download it?
Sent from my Nexus 7 2013 using Tapatalk
Click to expand...
Click to collapse
Like faux or Franco apk...?
Nope it's up to you to take a look at bricked.de ....

sgs505 said:
Like faux or Franco apk...?
Nope it's up to you to take a look at bricked.de ....
Click to expand...
Click to collapse
For the moment. I am working on a big version 2.0 update which will make that feature list explode.

show-p1984 said:
For the moment. I am working on a big version 2.0 update which will make that feature list explode.
Click to expand...
Click to collapse
Can we tell you wishes for the new version ?

sgs505 said:
Can we tell you wishes for the new version ?
Click to expand...
Click to collapse
Sure: https://github.com/showp1984/KControl/issues?state=open
Tag it as "enhancement"

show-p1984 said:
Sure: https://github.com/showp1984/KControl/issues?state=open
Tag it as "enhancement"
Click to expand...
Click to collapse
lol now i had to understand how github works ...:silly:
hope i did it well ( not so sure ) ...

Any recomendations for a battery saving configuration?
Would like to improve battery life, undervolted allready and im not seeing any improvments...
THX

oliverano said:
Any recomendations for a battery saving configuration?
Would like to improve battery life, undervolted allready and im not seeing any improvments...
THX
Click to expand...
Click to collapse
These are the more 'simple' settings:
Mpdecision->Simple Settings: Hotplug slow / unplug fast
Mpdecision->Simple Settings: Disable input event boost
Governor: Powersave or interactive
KControl provides you with way more "in depth" options, but those values will depend highly on your usage and are best left at defaults for the average user. If you are experiment happy, try fiddling with them (and set apply on boot off). If you don't like them you can just reset them through KControl or reboot and the kernel will be back to defaults