Related
To start off, I'm running Android Revolution 5.1.4 with the included "Buzz" kernel and recommended radio. I've looked all over xda, and I've yet to find any decisive, hard evidence that setCPU screenoff and "battery saver" profiles do anything to save battery life. Theoretically, I don't see any reason to think that cranking the cycle rate all the way down will save battery, as this just forces the processor to work harder for longer. Nonetheless, I imagined that some reduction in the form of a screen off profile would be beneficial, and I've been looking for the "sweet spot" for a few days now. However, so far, my anecdotal experience tracking currentwidget logs with screen off and wifi on (using Apache's smartass scaling) has been that, while the "lows" are lower when I set profiles to drop the cycle rate with moderate severity, there is greater variability in current draw, with many more "high extremes" (e.g. in the 100-250 range - even on "powersaver" scaling). When I set it and forget it at or slightly below stock, it doesn't get as low, but the variability is greatly reduced, leading me to imagine that the overall battery savings are greater. So far, all I think I've shown to myself is that cranking it below a certain level is useless, and it may yet be worthwhile to keep screenoff profiles within a higher middle range. However, I do have to wonder if the variability I'm seeing when running profiles (vs. one, manually adjusted flat rate) doesn't have something to do with the way they are implemented in setCPU.
Anyone out there with real, definitive proof that setcpu profiles actually work? I've seen lots of speculation and lots of "recommendation" but no proof as of yet. Not a programmer, just a social scientist with too much time on his hands. Any info/thoughts would be appreciated. I'll keep messing around and see what I find.
The definitive proof is on another, similar device:
A laptop.
Laptops regularly slow down the clock cycles and undervolts when in battery / powersaver mode, and there's proof of extended battery there.
So there's no reason to think it won't work for a phone...
Hell, I do it with my Inspire. I have it set on smartass at ~500MHz for battery usage (with other profiles at 0% priority at stock 1GHz and OC'd 1.5GHz for when I want it).
Team doubleshot kernel project.
Unfortunately the developer is unable to post source for these kernels at this time. Because of this, I am closing this thread and removing the download links. If you have any questions about GPL compliance, feel free to read this post.
Updates listed here:
-Added new version of 1.5 kernel in post 3.
-Added 1.7 kernel in post 3.
-Added CPU frequency table list in post 5.
Table of Contents:
General:
Post 01 - Info & Stock kernels
Post 02 - Undervolt kernels
Post 03 - Overclock kernels
Post 04 - Reserved - yogi2010
Post 05 - Reserved - Blue6IX
Note:
A kernel takes at least a solid 24 hours to finish building caches and get itself fully installed and humming.
Even that depends upon usage to a degree, so make sure that you give your kernel ample time to settle in before you start to evaluate it's performance.
Stock kernels
Gingerbread
Stock HTC 2.6.35.10 (Gingerbread) kernel
- 1.2GHz maximum CPU clock speed.
- Undervolting? No
- Insecure boot, see below:
boot.img - Insecure (default.prop):
Code:
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.service.adb.enable=1
kernel Info:
- Unmodified HTC 2.6.35.10 kernel source, compiled from the HTC Dev kernel source download.
- 1.2GHz maximum CPU clock speed.
Compatible ROMs:
- Stock 1.28.531.9 or 1.28.531.10
- Bulletproof 1.1
- ?
In-compatible ROMs:
- 1.55.531.3 software base
- ICS Roms
- ?
File Details:
MD5: b8aafcbc2447bae9839af4707bfcb38b
Size: 3.57 MB
Stock HTC 2.6.35.10 (Gingerbread) kernel Version 2
- Same as above stock kernel, except:
- Insecure boot with mock locations, see below:
boot.img - Insecure (default.prop):
Code:
ro.secure=0
ro.allow.mock.location=1
ro.debuggable=1
persist.service.adb.enable=1
File Details:
MD5: a6c227bf60ff4a100760fef0ef9bc68d
Size: 3.57 MB
Custom kernel management:
Installing custom kernels:
[1] - Download the kernel zip file to your sdcard.
[2] - Flash through clockworkmod recovery just like a ROM.
- If you do not know how to do this, you should learn how to flash ROMs before moving on to kernels.
SetCPU
- SetCPU is an app that lets you regulate the clock speed of your device. ( and more! )
- Check out the app in the XDA News page, and then check out the Dev thread.
- Consider donating and buying the market app to support the developer if you really use the app.
Custom kernel information:
WARNING:
Flashing a kernel meant for 1.28.539.9 or 1.28.539.10 software on 1.55.531.3 software will most likely result in boot loops. The boot.img files are structured differently.
Make sure you are flashing the right kernel for your software version or ROM.
Undervolt kernels
Post 02 - Undervolt kernels
The post on undervolt kernels will contain kernels focused on the battery savings that undervolt can bring. Some undervolt kernels may be overclocked.
Undervolt kernels will send less power to your CPU and save you battery power.
In extreme cases this can cause brownouts or maybe not being able to recover from sleep mode - but no actual damage to the device can result from undervolting.
Significant battery savings can be gained through undervolting depending on usage and implementation.
WARNING:
Installing an Overclock kernel on your device could have negative physical consequences (Read: broken hardware) if misused/abused.
Please educate yourself on what overclocking does and how you can melt your processor.
You proceed at your own risk and any damage that may result is the sole responsibility of the end user.
Overclock kernels
Post 03 - Overclock kernels
The post on overclock kernels will be focused on pushing the limits of the clock speed for the device. Some overclock kernels may be undervolted.
Qualcomm, the manufacturer of the Snapdragon chip in the device rates them at 1.5GHz. Here is a Snapdragon Product Overview that may help you track down more information about the Series 3 Snapdragon processor in the doubleshot.
In extreme cases overclocking can melt your processor. Direct physical damage can result from increasing the CPU or GPU clock speeds above manufacturers recommended speeds.
Anyone intending to use an overclock kernel should first familiarize themselves with the device hardware and implement such things at their own risk.
Further information:
XDA Links:
- [KERNEL][20 OCT][2.6.35.14] Kanged v0.1 | OC/UV
Thanks Romanbb for starting doubleshot kernel development!
- Boot image info.
- To be announced...
Off-Site Links:
- PDAdb entry for the doubleshot
- PDAdb entry for Snapdragon Processors
- PDAdb list of Snapdragon S3 Devices
- More to follow...
doubleshot Undervolt kernels
Gingerbread kernels:
UV5 HTC 2.6.35.10 (Gingerbread) kernel
- 1.5GHz maximum CPU clock speed.
- Undervolting? Yes
- Insecure boot, see below:
boot.img - Insecure (default.prop):
Code:
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.service.adb.enable=1
kernel Info:
- Hefty undervolting, especially at the lower frequencies.
Compatible ROMs:
- Stock 1.28.531.9 or 1.28.531.10
- Bulletproof 1.1
- ?
In-compatible ROMs:
- 1.55.531.3 software base
- ICS Roms
- ?
File Details:
MD5: a0b252d36bf39f788cdcb54e29717971
Size: 3.57 MB
UV6 HTC 2.6.35.10 (Gingerbread) kernel
- 1.5GHz maximum CPU clock speed.
- Undervolting? Yes
- Insecure boot, see below:
boot.img - Insecure (default.prop):
Code:
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.service.adb.enable=1
kernel Info:
- Even more undervolting, lowered voltages from UV5 on some of the mid-range frequencies.
Compatible ROMs:
- Stock 1.28.531.9 or 1.28.531.10
- Bulletproof 1.1
- ?
In-compatible ROMs:
- 1.55.531.3 software base
- ICS Roms
- ?
File Details:
MD5: fd8055865b09a645d3c3030ecce4ef40
Size: 3.57 MB
More Info:
I made these UV kernels because i wanted to play with undervolting and see if i could extend the battery life on the device..... it seems to have worked out well for me so far, i have been using the stock battery since last night, and today am still at at least 85% battery left. I hope you too will experience improved battery life! I am surprised at how much I have been able to lower the voltages and still maintain stability..... i haven't had a single freeze-up or glitch yet! But if you do encounter anything like this, try the UV5 kernel above, which has slightly higher voltages than the UV6. And also I would keep a copy of the kernel with stock voltages handy
I have also been using SetCpu to set my min. frequency down to 192(default is 384 i believe), and i haven't had any lockups or problems with that either. So between that and the UV, my phone seems to be using little power while in sleep mode.
I will probably experiment with even more undervolting soon, and will notify of updates here in the thread. i can also post or provide the exact voltages for these kernels for anyone interested. enjoy!
Overclock kernels
doubleshot Overclock kernels
WARNING:
Installing an Overclock kernel on your device could have negative physical consequences (Read: broken hardware) if misused/abused.
Please educate yourself on what overclocking does and how you can melt your processor.
You proceed at your own risk and any damage that may result is the sole responsibility of the end user.
Gingerbread kernels:
OC 1.5-A HTC 2.6.35.10 (Gingerbread) kernel
- 1.5GHz maximum CPU clock speed.
- Undervolting? Slight
- Insecure boot, see below:
boot.img - Insecure (default.prop):
Code:
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.service.adb.enable=1
kernel Info:
- Modified CPU table to accomodate Qualcomm 1.5GHz S3 Snapdragon chip speed.
- HTC cuts it off at 1.2GHz on the stock kernel.
- Re-scaled CPU table and L2 cache.
- Max voltage 1.2 volts even at 1.5GHz (HTC was 1.25 volts @ 1.5GHz)
Voltage tables to be posted later - no voltages exceed what the stock kernel came pre-coded with, and we have undervolted the 1.5GHz frequency to 1.2 volts instead of the 1.25 volts HTC put it in for. Runs fine at 1.2 volts, has been for months for me.
(we used that 1.25volts at 1.7GHz instead...)
Otherwise all voltage tables are back to HTC stock, and new frequencies leading to 1.5GHz HTC did not put in had the voltage used from the lower frequency beneath it.
1.5 GHz is where the 'Two-Headed Snapdragon takes flight'.
(quote is the title of a Snapdragon white-paper)
The idea here is to give the superscaler dual-core processor the scaling options to choose from to take advantage of that ability...
Compatible ROMs:
- Stock 1.28.531.9 or 1.28.531.10
- Bulletproof 1.1
- ?
In-compatible ROMs:
- 1.55.531.3 software base
- ICS Roms
- ?
File Details:
MD5: e866dc2eed625dfdbcc22fec4e7a0b8f
Size: 3.57 MB
March 17th, 2012
OC 1.7-A HTC 2.6.35.10 (Gingerbread) kernel
- 1.7GHz maximum CPU clock speed.
- Undervolting? Slight
- Insecure boot, see below:
boot.img - Insecure (default.prop):
Code:
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.service.adb.enable=1
kernel Info:
- Modified CPU table to extend to 1.7GHz clock speed.
- Re-scaled CPU table and L2 cache.
- See post 5 for the list of CPU frequencies.
- Max voltage 1.25 volts at 1.7GHz (HTC had 1.25 volts @ 1.5GHz)
We used the 1.25 volts HTC laid out for the 1.5GHz frequency for our 1.7GHz frequency instead. Runs great! ...and we stay within a voltage level that was already recommended to us through the code by HTC, so we are probably not putting too much voltage through the chip yet.
(we'll even see if we can knock that down a bit too, soon)
If 1.5GHz is where the dragon takes flight, then 1.7Ghz is where it starts razing villages ~ !
1.7GHz is where this device is most comfortable (in my opinion).
NOTE: 1.7GHz is above ANY manufacturer recommendations - you are your own warranty now. (pay out of pocket for breakage - you've been warned)
...The idea here is to give the superscaler dual-core processor the scaling options to choose from to take advantage of that ability:
I said that in the 1.5 kernel, but it's moreso true in this 1.7 one. There are a lot of options for frequencies that the Scorpions can use to scale to exactly the right level of effort needed to get the job done.
I am not sure at what point the table becomes too bloated and we see a hit on performance. I doubt very highly we've hit it yet, especially given the testing i've been doing - this is more a worry for pushing higher then 1.7GHz then here, but something to put out there now.
Compatible ROMs:
- Stock 1.28.531.9 or 1.28.531.10
- Bulletproof 1.1
- ?
In-compatible ROMs:
- 1.55.531.3 software base
- ICS Roms
- ?
File Details:
MD5: 8a55ea04d6f27bb142119b589fa7ea95
Size: 3.57 MB
March 17th, 2012
here is a screenshot of my battery usage with the UV6 kernel, on the stock 1.28.531.10 ROM, rooted and debloated of course, and using the stock battery. granted, i slept 7 of those hours, and i wasn't on the phone constantly, but i put in at least moderate data and texting use, and a quick call or two. i'm decently happy with it so far.
there hasn't been a ton of support for what HTC has done, software-wise, with our device, but i tend to think it runs pretty well, and that kudos are deserved. the 1.55.531.3 ROM especially seems nice and balanced, with steady battery drain, and few bugs. we would like to develop for the that new update, but for now are basically learning and working with what kernel source we have.
1188000 is considered the 1.2GHz rating by HTC/T-Mobile. (device manufacturer and carrier.)
Qualcom rates the chip at 1.2GHz recommended, 1.5GHz maximum. Every other device that has this chip runs at 1.5GHz.
...how is this fair to us?
Granted - they are trying to do a good thing - no doubt this is part of a solution to the battery issue after they got data back from the earlier Sensation launch.
In a lot of ways the doubleshot is singled out for being nerfed, Most of the people who would've gotten this device got the Sensation instead (basically the same device) because it launched a bit sooner. Then this gets nerfed on top CPU speed and turns away more potential buyers who go by the numbers in-store to compare.
So, now we fix - with HTC releasing the source code to the kernel a while ago, we can now do this ourselves and wake up the sleeping dragon at the heart of the doubleshot.
Suddenly, it's all okay - - the manufacturers decisions based on how they wanted to market the hardware are no longer something we have to just deal with and grumble about, now we can just go ahead and tailor the device to suit our needs.
I spent a significant amount of time crawling through the kernel source surrounding the specific hardware being used in the doubleshot, and ran around tracking down any scrap of information I could about the components and how they work. I bought the doubleshot based on it's hardware and what it was capable of.
Between all the device documentation found and the countless hours wide-eyed in wonder drifting through the kernel source for the device, I was able to employ everything I learned about overclocking desktops and graphics cards over the years.
I sat down with my calculator and ran all the numbers to make a nice, mathematically balanced table based on the various multipliers that make up the device's internal speeds across the hardware inside.
This project was, and is, a goal of mine since before buying the device, and thanks to yogi2010's help it's becoming a reality.
Please forgive me for not having my source set up for download yet, I will get to that as soon as I can - meantime i've kept very detailed records and will get it all together and available.
Thanks for your patience on this!
Look forward to a nice and re-scaled 1.7GHz kernel soon...
Then I can spend some time on experimenting above 1.7GHz...
Mathematically there should be a bunch of frequencies available, but they are not as harmonious to the various multipliers involved and theoretically some of them should be unstable.
I don't recommend anyone run over 1.7GHz as the risk of permanent damage to the device becomes pretty severe after that.
Increases in the system speed like this, beyond manufacturers ratings, can be very dangerous in a permanently damaging way. I continue on for curiosities sake, and I have a doubleshot that I purchased privately, out of manufacturers warranty and with no insurance plan.
In short, I have a device I can melt and there isn't a person I can cast blame on beyond myself, for surely no one else is at fault when I eventually break it doing this.
Even if no immediate damage results from pushing the device far past it's design limits, the long-term lifespan of the device is dramatically reduced. The types of stresses I intend to put the machine through are not anything near normal or what it was designed for.That all being said -
I'm curious. I'm driven to know, and so I want to see for myself first-hand what it can do.
The rule to overclocking is to find your boundaries and then work out the maximum stable settings you can use in both directions.
...Finding the low end of the spectrum is no biggie, can't hurt undervolting or underclocking anything on it...
...Finding the top end of the operating range, though, is a destructive art by nature.
I wouldn't want to put something I wanted to rely on and last me a while through this - a desktop, maybe ... a small electronics device, especially one like this?
I will likely get a lot of use out of the second device because it shouldn't kill it in just finding the boundaries, but it will likely be replaced with another doubleshot when it starts to die and retire into salvageable parts for repairs.
In short: I bought a device to use for development and curiosities sake - it's not even attached to a plan. Be aware of the stresses overclocking can have on your device and think carefully before overclocking your device.
Once again, I do NOT recommend running above 1.7GHz - I do see a noticeable level of improvement in FPSE playing Castlevania: Symphony of the Night, and the benefit of reasonable overclock is real. Above 1.7GHz is not reasonable but possible.
If we had more RAM, we could hold a higher stable speed, but the device performs admirably and is something I am proud to own. HTC and Qualcomm did a damn fine job on the hardware this thread is about.
Just about any gripes I have about the device are limitations of software, be it apps, the OS or the kernel itself. Since we have the 2.6.35.10 source we can work on fixing things like this and more.
kernels take time to develop, but having control over how the device physically operates enables you to streamline it's processes and do it's job more efficiently.
I look forward to the HTC release of the kernel source for the 2.6.35.13 kernel from the OTA!
Projects like this would not exist without the open source community and places like XDA.
Thank you all.
Yay, kernel development!
Have you guys tried to push past 1.5ghz?
Sent from my Transformer Prime TF201 using XDA
daniel60104 said:
Yay, kernel development!
Have you guys tried to push past 1.5ghz?
Sent from my Transformer Prime TF201 using XDA
Click to expand...
Click to collapse
yeah, i think Blue is gonna work on that next
so far, the kernel seems to be working well on Rubix ICS 5.3. I'm gonna leave it uncharged over night and report back on the battery drain.
daniel60104 said:
Yay, kernel development!
Have you guys tried to push past 1.5ghz?
Sent from my Transformer Prime TF201 using XDA
Click to expand...
Click to collapse
yogi2010 said:
yeah, i think Blue is gonna work on that next
Click to expand...
Click to collapse
...so yea, higher clock speeds are coming. But kernels aren't like apps and other stuff.
Supposing I had a freshly compiled kernel and installed it right now, it takes at LEAST 24 solid hours to settle in - and even that is highly dependent upon usage.
So you would be looking at several days of direct testing just by myself just off of one compile operation to start to get good readings - one thing you can't rush are kernels. It might run fine for 6 hours then start bugging out, you really have to just use it to know for sure.
I don't like to just toss stuff out there and hope for the best and with overclocking it's even more important. If there's going to be a problem, especially one that may result in physical damge, i'll find out on my own device(s) first before releasing anything.
This is not the kind of thread you should expect daily software updates in, it's a longer process then that.
I remeber when tbalden was creating his kernels, he had to turn off the (infrared?) Sensor which controls auto back light adjustment, as well as the keyboard light. The workaround for the keyboard was to always have it on whenever the phone was on/keyboard was out. Diabling the sensor resulted in MASSIVE battery savings, in addition to the undervolt work he did. Perhaps we can implement this in one of the undervolt kernels? In my mind, it should be extremely safe, because it does not affect the current/voltage or even the CPU in any way.
Here's what I got for my first run with rubix 5.3. Screen on for 3 hours total. I clocked it to 1.5 with an on demand governer. My alarm was going off for about two hours this morning, which is the beginning of the drop off. During those two hours, the screen was on, and it can be assumed that the CPU was at max the whole time or most of the time.
Over all, its looking pretty good. This is with the v6 kernel.
dung8604 said:
I remeber when tbalden was creating his kernels, he had to turn off the (infrared?) Sensor which controls auto back light adjustment, as well as the keyboard light. The workaround for the keyboard was to always have it on whenever the phone was on/keyboard was out. Diabling the sensor resulted in MASSIVE battery savings, in addition to the undervolt work he did. Perhaps we can implement this in one of the undervolt kernels? In my mind, it should be extremely safe, because it does not affect the current/voltage or even the CPU in any way.
Click to expand...
Click to collapse
Ah ok, thanks for the tip. It sounds interesting and I would be willing to try and implement his tweak, if it was ok with him. At this point it would be good practice and learning for me to try different tweaks and edits to the kernel, so I will look into it and perhaps can at least have a version of the kernel for people who wish to use this tweak. I will need to look at his code and/or probably have tbalden give me some pointers on how to implement this... unless it is a simple edit to turn that sensor off.
Anyway, thanks for the tip, and for the screenshot of your battery usage. Was that with the stock bettery? The funny thing for me is, I SEEM to be getting better results with the stock battery than with my Anker! Not sure if my Anker is going bad or what.
yogi2010 said:
Ah ok, thanks for the tip. It sounds interesting and I would be willing to try and implement his tweak, if it was ok with him. At this point it would be good practice and learning for me to try different tweaks and edits to the kernel, so I will look into it and perhaps can at least have a version of the kernel for people who wish to use this tweak. I will need to look at his code and/or probably have tbalden give me some pointers on how to implement this... unless it is a simple edit to turn that sensor off.
Anyway, thanks for the tip, and for the screenshot of your battery usage. Was that with the stock bettery? The funny thing for me is, I SEEM to be getting better results with the stock battery than with my Anker! Not sure if my Anker is going bad or what.
Click to expand...
Click to collapse
no, this was with my anker. I'm much more concerned about standby time. It is my full belief that if you're using the phone, there is only so much that can be done to help battery drain. Right now isn't such a good test of standby time, as I use my phone at work quite a bit.
Regarding tbalden's edits, I would love to use these features. I hardly ever have the auto backlight on anyways, and I would rather have the keyboard always on than rely on the type of lighting it is in. Just seems more convenient and logical to me that way. Additionally, the drain from the keyboard always being on is nothing compared to the drain required to use the front sensor.
Also, from my experience with tbalden's roms, nothing else is affected by deactivating the auto backlight sensor.
dung8604 said:
no, this was with my anker. I'm much more concerned about standby time. It is my full belief that if you're using the phone, there is only so much that can be done to help battery drain. Right now isn't such a good test of standby time, as I use my phone at work quite a bit.
Regarding tbalden's edits, I would love to use these features. I hardly ever have the auto backlight on anyways, and I would rather have the keyboard always on than rely on the type of lighting it is in. Just seems more convenient and logical to me that way. Additionally, the drain from the keyboard always being on is nothing compared to the drain required to use the front sensor.
Also, from my experience with tbalden's roms, nothing else is affected by deactivating the auto backlight sensor.
Click to expand...
Click to collapse
I agree completely with what you are saying, both in theory and in practice.
Something else to consider is that it checks the light sensor every 3-6 seconds or so - so that constant CPU usage is also eliminated which not only saves you from having to do that check in the first place, but saves from interrupting (or scheduling around...) other processes happening.
Ideal is what you have said - light on when keyboard out - light off when keyboard closed. You don't need the backlight otherwise.
The only reason I haven't looked further into it yet is because I want to tone down the intensity of the 4 front-facing buttons and as yet there is no way to do so without dropping the illumination level of the keyboard too. A workaround will have to be created to deal with this.
I have a privacy screen protector on my device, so even at the brightest screen setting it is considerably dimmer then the buttons in dim or no light - and it bothers me since my eyes are so sensitive to light.
There are a couple of ways to attack the light issue - one of them is certainly on the kernel level. Appreciate the suggestion!
Towards you and everyone else - some things suggested like this are great idea but may not be immediately implemented for a variety of reasons. Adding another variable to the testing we are doing could skew the results, and it's another thing to keep track of during said testing as a start.
On finished, stable kernels that would be a good thing to implement, but for both our internal testing and the live testing you guys will all be doing for us don't count on things like that right away. As kernels prove out the mods they have been slated for then things like this can be built in. Start with a stable, solid foundation and you can support as many frills as you want...
I don't write this to discourage suggestions - quite the opposite - just trying to give a small window into a bit of the process behind creation so people can understand what's going on a tad more.
Blue6IX said:
I agree completely with what you are saying, both in theory and in practice.
Something else to consider is that it checks the light sensor every 3-6 seconds or so - so that constant CPU usage is also eliminated which not only saves you from having to do that check in the first place, but saves from interrupting (or scheduling around...) other processes happening.
Ideal is what you have said - light on when keyboard out - light off when keyboard closed. You don't need the backlight otherwise.
The only reason I haven't looked further into it yet is because I want to tone down the intensity of the 4 front-facing buttons and as yet there is no way to do so without dropping the illumination level of the keyboard too. A workaround will have to be created to deal with this.
I have a privacy screen protector on my device, so even at the brightest screen setting it is considerably dimmer then the buttons in dim or no light - and it bothers me since my eyes are so sensitive to light.
There are a couple of ways to attack the light issue - one of them is certainly on the kernel level. Appreciate the suggestion!
Towards you and everyone else - some things suggested like this are great idea but may not be immediately implemented for a variety of reasons. Adding another variable to the testing we are doing could skew the results, and it's another thing to keep track of during said testing as a start.
On finished, stable kernels that would be a good thing to implement, but for both our internal testing and the live testing you guys will all be doing for us don't count on things like that right away. As kernels prove out the mods they have been slated for then things like this can be built in. Start with a stable, solid foundation and you can support as many frills as you want...
I don't write this to discourage suggestions - quite the opposite - just trying to give a small window into a bit of the process behind creation so people can understand what's going on a tad more.
Click to expand...
Click to collapse
Point taken. It is important that we understand the full effects of overclocking and undervolting only before we introduce other such factors. That being said, tbalden's kernels have proven the stability and useability of the tweak. However, introducing the tweak at this stage would have us second guess the UV effects.
I will say that at the moment, v6 kernel seems to be extremely stable on rubix 5.3. I have little interest in overclocking my device past 1.5 GHz, and the only time I do so is at intial setup when I'm running restores and such. I almost always keep it clocked around 1 GHz. And since I have no interest in bechmark scores, I should rarely, if ever, have to overclock it past 1.2 GHz. Maybe when I'm using the tv out function.
Blue, can you provide a table of frequencies and percentage of undervolting that was applied to the frequency? This is just out of curiosity, so if you don't have time or the want, then don't worry about it.
dung8604 said:
Point taken. It is important that we understand the full effects of overclocking and undervolting only before we introduce other such factors. That being said, tbalden's kernels have proven the stability and useability of the tweak. However, introducing the tweak at this stage would have us second guess the UV effects.
I will say that at the moment, v6 kernel seems to be extremely stable on rubix 5.3. I have little interest in overclocking my device past 1.5 GHz, and the only time I do so is at intial setup when I'm running restores and such. I almost always keep it clocked around 1 GHz. And since I have no interest in bechmark scores, I should rarely, if ever, have to overclock it past 1.2 GHz. Maybe when I'm using the tv out function.
Blue, can you provide a table of frequencies and percentage of undervolting that was applied to the frequency? This is just out of curiosity, so if you don't have time or the want, then don't worry about it.
Click to expand...
Click to collapse
i PM'd you some info, until we get our gits set up
Thank you, I saw that earlier. I must say, this is looking very promising:
Can 2 way call recording also be added to the kernel?
dung8604 said:
I will say that at the moment, v6 kernel seems to be extremely stable on rubix 5.3. I have little interest in overclocking my device past 1.5 GHz, and the only time I do so is at intial setup when I'm running restores and such. I almost always keep it clocked around 1 GHz. And since I have no interest in bechmark scores, I should rarely, if ever, have to overclock it past 1.2 GHz. Maybe when I'm using the tv out function.
Blue, can you provide a table of frequencies and percentage of undervolting that was applied to the frequency? This is just out of curiosity, so if you don't have time or the want, then don't worry about it.
Click to expand...
Click to collapse
I fully agree about the OC and benchmarks.
While in the beginning it was fun to see what I could squeeze out of this device,
I found that the marginal gain in real-world experience was not worth the battery
drain and extra heat on the processor.
I am running the v6 kernel with Blue's Bulletproof 1.1 and am getting 26+ hours
out of my battery (Sticker says it's an Anker 1900 but I think I got hosed because
every one of those battery widgets/apps show it as a 1580mAh :\)
Anyways, it's truly great to see so much dev, finally, for this device!
Thanks to all!
You didn't get hosed.
The kernel battery code is configured for the stock battery. The kernel I am running right now has that reset for the anker I'm using.
You can expect little fixes like that later, right now we are exploring OC/UV primarily - but that doesn't mean we aren't fixing things on the side even though those changes aren't mainlined yet.
We'll get our PLL tables posted and our kernel code in GIT but for the moment sorry that we haven't yet.
I've been giving every spare second I have to doing this, and there are still a bunch of loose ends to clean up.
I'm on lunch break from my 4th straight work shift in a row - another few hours and I'll have the evening off before another shift tomorrow - one day this week I will have to sleep too.
If I didn't need the money I would blow off some of these shifts and just dev for the doubleshot, but I can't afford to miss any work available, so bear with us as we get this put together.
Sent from my Bulletproof_Doubleshot using xda premium
Hello guys
I'm not a new user in kernels or ROMs .
I have a low-decent battery life ,and I'm sure there's a way to get a better battery life with undervolting .
I want to know
what is "undervolting" ?
What is the biggest damage it can cause?
What is PVS?
How do I know ,how much I can UV?
What are the steps to undervolt?
What I gain from UV (despite battery life)?
For your info ,I'm using AOSPAL ROM +FAUX's latest 16u kernel .
Thanks
Sent from my Nexus 5 using XDA Premium 4 mobile app
http://forum.xda-developers.com/showthread.php?t=2537000
Sent from my Nexus 5 using Tapatalk
Hi,
Most of your questions have a reply:
About undervolting: http://forum.xda-developers.com/google-nexus-5/general/nexus-5-undervolting-thread-t2537000.
CPU binning: http://forum.xda-developers.com/google-nexus-5/general/cpu-binning-nexus-5-t2515593.
The "risks" are instability like hard reboot, SOD, etc.... To find a "safe" value you will need to test by yourself to find what undervolting your CPU can handle, not all CPU's are equals.
Undervolt by steps like - 25mV, don't set your new values at boot unless your are sure it's stable (or you could encounter bootloop), test for a few days under different conditions (as your use).
The gain apart battery life (but you will not gain that much as people tend to think) is a little less heat, but again nothing huge..., better is to test by yourself and see what you will gain... or not.
Battery life depends mainly of your use, apps, signal quality and settings like, screen brightness, synchro, CPU governor, etc... In my opinion check first what could be the cause of your low battery life (and what is low battery life for you???) before play with undervolting.
As said above, undervolting will get you very minor battery life increases.
More than likely you have an issue, or its just your setup and usage giving you the battery life you are seeing.
Undervolting will not change any of this.... You'll gain only minutes of battery time.
Try some troubleshooting in the below thread to see if you have an issue, or how to setup for better battery life. Read through it a bit, from the last page and work back a bit. You can post meaningful screenshots there too. From gsam or BBS.... not the stock battery screen, it has no real useful info for finding issues. Good luck!!
http://forum.xda-developers.com/showthread.php?t=2509132
Nexus 5 Battery Results
I've been undervolting many systems for many years, primarily Linux desktops and some servers, and the primary benefit is that you get less heat output which means when running cpu-intensive tasks the temperature climbs slower so the throttling of the clockspeed kicks in later, so your phone will be faster in certain situations. If you take a phone which has been idle for a while and run a benchmark, and then immediately run that benchmark again, the 2nd time gets a lower result as the phone is still hot from the 1st. This makes drawing conclusions about settings really dificult but it illustrate that throttling from heat is affecting speed.
For most users their perception will be the phone runs cooler.
You do undervolt at each step in the processor's frequency, and each step is a trial+error activity, the throttling I mention means finding a stable under-volt at the higher frequency which is labour-intensive,i.e take the max clock, and undervolt it a little, run a benchmark which forces it to run at high clockspeed, and if it passes that test then run it again at the next step down in frequency. Once you've got the most stable top clockspeed, then do it progressively for all the other voltages on the way down.
In some platforms in Linux and Windoze, we wrote scripts which save the stable voltages and then undervolts a little and runs a stress-testing benchmark and if the system hung it wouldn't save the current voltages so the previous higher voltages were safer, stick that script in a startup script area and leave the compute to do many self resets, and you've calculated your device's voltage range. I wonder if someone has that done for Android??? For a laptop the FAN would run slower saving battery time and for laptops that would lead to say 20% better battery life but on a phone it won't make much saving as no fan.
Your phone will run most of its time (like 95%) at its lowest frequency, so for effort/benefit just focusing on dropping its voltage will gain the most in the phone running cooler.
Battery life improvement is marginal, if you look at your battery stats its down to your application settings and screen brightness, i.e. how you use and what you do with your phone. So if your battery life is bad, use your phone less!
I carry a slim USB battery, it is the $/effort/benefit the best thing you can do, $20 doubles your battery life, if you get one with a 1.5A-2A output in just a few minutes when the phone doesn't mind a battery attached, will dwarth every possible tweak and hack anyone can form in benefit.
I am running MoKee with pretty decent battery life but am currently experimenting with reducing screen resolution and tweaking CPU & GPU settings (using Kernel Aduitor) to see if I can squeeze more out of a charge. Not really sure what the best settings are to maximise battery while keeping smooth everyday performance (I don't game or do any very heavy tasks or multitasking). I thought that it might be possible to get near SD625 stamina from the SD820 seeing as they are both built on the 14nm process, but the architecture is very different (ours has the quad-core big little set up with kryo, as opposed to the 625's octa-core A53 set up). At the moment I am trying it with the little cores left at default and the big cores max frequency down clocked by about 25%. I haven't changed the governors. I also down clocked the GPU max frequency a bit. Anyone have any advice regarding an optimal set up?
Not sure about the best settings but for sure I'm waiting for your feedback regarding this change and battery life. It should be improving it, but nobody knows how much.
Also I've noticed that in youtube if there is 720p or 1080p, the default setting is 720p (of course our screen is a multiple of 720p).
Are the pixels visible?
Couldn't see pixels with reduced screen resolution, even at 720p. Of course it's only rendering a lower resolution image then stretching it over the physical
1440p display. The result is just a softer image. Looks a bit strange, but 1080p wasn't too bad. However, didn't seem to have any effect on battery life and surprisingly at 720p I got a worse Antutu score than normal, so I have given up and returned to 2K.
I feel sorry for that I was really hoping for some way to increase the battery life a bit.
Hey guys... Today I found something interesting in our German Android forum. There's a group of people who are developing a great Rom for our device. It's just called the telegram Rom.
So the Rom will include scripts tweaks and a full working app for changing governors. So you will be able to get a much better battery life. The German guys talking about 20 to 30 percent extra power for our device.
The hole project behind this was founded here on xda but mainly developed for the Oneplus-3.
But in fact the whole workaround is working on any device that's running a SD820 processor.
Here is the link to the site
https://forum.xda-developers.com/oneplus-3/how-to/advanced-interactive-governor-tweaks-t3476589
So maybe you like to have a look. There are also complete explanations of how the SD820 works related to energy management and voltage at minimal and maximum clock speed!
I hope this can answer your questions.
Thanks for sharing Lizard82.
I follow the thread and use AKT... i am using the profile called Project Zhana & X.A.N.A v4.2. 14 hr sot is unheard of but I am getting close to 6hrs sot with xposed loaded which I am already impressed. It is is way better then what I used to get around 3 hrs sot. I am running revolution 21s rom which is very similar to EUI and not the most optimized rom with heavy battery drain. and I am happy that this phone finally has a good battery life. Appreciate Lizard82.
The sot really depends of what you do with the phone, and what apps run when the phone is on idle. I changed the resolution to 1080p but didn't notice any difference, so I went back to 1440p. There are tons of threads about kernel Adiutor, you won't have a hard time finding it
For best battery on Nougat I did this on Nexus 7.1 and AOSP 7.1 roms with BS kernel:
- Use rom that can use Black Screen kernel 2.1/2.2 or later
- Use kernel Adiutor to change CPU governor to impulse (or Darkness)
- Set value in Govenor tuneable (locate just under CPU Governor touch it to go inside to change value) : highspeed_freq to 307200, set Powersave_Bias to 1. I changed both BIG and LITTLE CPU core in kernel Adiutor.
- I think keep AKT profile on stock/unchange no need to set it is ok
Hi XDA community!
I was doing research in to the current custom kernels available for our phone. Pretty much every kernel developer advertises their kernel as having improved performance and battery. One of the problems I found is that it is quite difficult to compare the performance and battery of kernels without trying it out for a week or so. I thought for the benefit of not only myself (who doesn't have time to test every kernel), but for the community that it would be helpful to have a thread that compares kernels.
Each post being a short comparison of at least 2 kernels should be sufficient. Performance, battery life, conditions (e.g. ROM, heavy user? non-gamer? etc. ) and special features (that set it apart)of a kernel would be good ways to compare them. Perhaps a quick rundown of your current kernel and why it suits your needs best could be good as well.
This is not a thread to tell me what you think the best kernel is. I believe that all custom kernels have their merit being somewhere on the balance between battery life and performance + a few features and suiting different people based on their needs.
Gonna reply to this thread I made a while ago after a bit of testing. I think it would be a good starting point for anyone who is indecisive with kernels.
Today I thought I'd compare 2 kernels that I've been using a fair bit recently. Both are based on S7 edge firmware, but have counterparts for S8 ROMs. The disclaimer is that I didn't have time to try every version of the kernels, nor will I promise that my experience will be the same as yours.
Tkkg1994's Superstock vs Farovitus' Notorious kernel
The competitors
Superstock kernel
Created by the famous developer of Superman, Superstock, Batman and Ironman ROMs.
Recommended by the developer himself over his other more modded kernel (Superkernel)
Stock Samsung values for CPU and GPU speed
Safety net green
Other performance/battery enhancements as laid out on his page https://forum.xda-developers.com/s7-edge/development/kernel-superstock-v1-3-5-t3453462 and below in the special features section.
Notorious kernel
Most popular custom kernel (by thread activity and likes)
Under clocked cores
Safety net green
Comes underclocked: Big: 312-1872 small: 234-1586
stock value for CPU speed
Plenty of performance and battery tweaks outlined in his page https://forum.xda-developers.com/s7...orious-kernel-tw-dqd1-g93xx-g93xxd-3-t3600711 and below in the special features section.
They both sound pretty good, but it's the real life performance that matters right?
Versions used
I've used super stock 2.7.1 and 2.9 (the versions that came with superman ROM 2.6 and 2.7 respectively). 2.9 will be the one discussed today. I have found the performance quite similar between the 2 versions however.
I've used Notorious 1.9.1
Kernel Mods (that I used)
Both were kept very close to how the developers intended
I changed the to IO scheduler on Superstock to Zen
And I changed the internal IO scheduler on Notorious to Row, external to maple
Both I used Westwood TCP congestion control.
Both I kept with the stock governor (interactive)
no undervolt for notorious kernel
Conditions - my ROM and usage pattern
Superman ROM 2.7 with Magisk root
Debloated
Black theme, wallpaper and ui etc.
clock widget xperia running
Force doze with significant motion detector disabled
Greenify privileged mode (pretty much all social messaging apps greenified)
Magisk module to doze google play services
I turned off pretty much all the advanced features: smart alert, smart stay, don't turn on when dark etc.
Auto brightness on.
BT always on (connecting to car and smartwatch)
Location always on
4g, volte and viLTE on
WiFi off (I got plenty of data)
Charged to ~75% at night every day
Use was moderate. Involved BT audio on 15 minute drive to and from work. Variable tasks being done on phone: calls, texting, messaging (whatsapp, messenger lite), looking up internet, occasional remote desktop. 8-9hr day at work. Some messaging, calls, texting at home but less than at work.
No games on phone - I have a busy job and I have a PC, PS4 and WiiU.
Performance
Superstock has very good performance. Absolutely no lags. UI feels smooth and fluid. I don't game however.
Notorious feels smooth and snappy despite being quite underclocked. Developer sped up the boot animation fps. Maybe it's in my head (and therefore insignificant if any), but possibly a bit slower to start apps. No lags however. Again, I don't game on the phone.
Battery
Superstock
Very good battery. A fair bit better than stock. I could lose between 1-4% overnight (6-9hr sleep). Never bothered measuring SOT but the phone lost on average ~20-25% per day moderate use as outlined above.
Notorious
Excellent battery. On my off days, I found that notorious enters deep sleep faster than superstock leading to less idle drain. It also seems to drain battery slower when screen on. Would lose 1-3% over a 6-9hr sleep. Average day would use up about 12-17% battery moderate use as outlined above.
Special features
Superstock is a plain kernel that just works out of the box. Not many modding opportunities - can adjust clock speed within the stock range. No voltage change. Can use the 3 basic governors. conservative, interactive (stock), on demand. Can change IO scheduler and TCP congestion algorithm. Only notable feature is the safety net green. A few services disabled according to the developer, but that is about it.
Notorious is very customisable with mtweaks many governors to choose from (I only bother using interactive). Under/overvolt and under/overclock avaliable for CPUs. Under/overvolt and under/overclock available for GPU. Boeffla kernel wake lock blockers. IO scheduler change, TCP algorithm change. I changed very few settings, but it is also commonly undervolted. On the thread, people liked to use bluactive, impulse and relaxed governors rather than interactive. With Notorious, I found that undervolting didnt really increase battery life much and gave me the increased paranoia of silent corruption/ instability. I change the TCP and IO so that it theoretically optimises my user experience. Realistically, I found no difference compared to stock and it was more for my obssesive compulsive side.
Verdict
For a non-gamer like me who uses the phone for calling, messaging, internet, video, music notorious provides more than adequate performance with greater battery savings than superstock.
Superstock I'd imagine to have much greater performance under a big load. It was subjectively more responsive and faster when doing my low power tasks.
At the end if the day both were much better than stock for me in terms of battery. I'd say that Superstock would be more for performance and Notorious would be more for battery saving. Any questions or comments, ask away!
Eggleston11 said:
Gonna reply to this thread I made a while ago after a bit of testing. I think it would be a good starting point for anyone who is indecisive with kernels.
Today I thought I'd compare 2 kernels that I've been using a fair bit recently. Both are based on S7 edge firmware, but have counterparts for S8 ROMs. The disclaimer is that I didn't have time to try every version of the kernels, nor will I promise that my experience will be the same as yours.
Tkkg1994's Superstock vs Farovitus' Notorious kernel
The competitors
Superstock kernel
Created by the famous developer of Superman, Superstock, Batman and Ironman ROMs.
Recommended by the developer himself over his other more modded kernel (Superkernel)
Stock Samsung values for CPU and GPU speed
Safety net green
Other performance/battery enhancements as laid out on his page https://forum.xda-developers.com/s7-edge/development/kernel-superstock-v1-3-5-t3453462 and below in the special features section.
Notorious kernel
Most popular custom kernel (by thread activity and likes)
Under clocked cores
Safety net green
Comes underclocked: Big: 312-1872 small: 234-1586
stock value for CPU speed
Plenty of performance and battery tweaks outlined in his page https://forum.xda-developers.com/s7...orious-kernel-tw-dqd1-g93xx-g93xxd-3-t3600711 and below in the special features section.
They both sound pretty good, but it's the real life performance that matters right?
Versions used
I've used super stock 2.7.1 and 2.9 (the versions that came with superman ROM 2.6 and 2.7 respectively). 2.9 will be the one discussed today. I have found the performance quite similar between the 2 versions however.
I've used Notorious 1.9.1
Kernel Mods (that I used)
Both were kept very close to how the developers intended
I changed the to IO scheduler on Superstock to Zen
And I changed the internal IO scheduler on Notorious to Row, external to maple
Both I used Westwood TCP congestion control.
Both I kept with the stock governor (interactive)
no undervolt for notorious kernel
Conditions - my ROM and usage pattern
Superman ROM 2.7 with Magisk root
Debloated
Black theme, wallpaper and ui etc.
clock widget xperia running
Force doze with significant motion detector disabled
Greenify privileged mode (pretty much all social messaging apps greenified)
Magisk module to doze google play services
I turned off pretty much all the advanced features: smart alert, smart stay, don't turn on when dark etc.
Auto brightness on.
BT always on (connecting to car and smartwatch)
Location always on
4g, volte and viLTE on
WiFi off (I got plenty of data)
Charged to ~75% at night every day
Use was moderate. Involved BT audio on 15 minute drive to and from work. Variable tasks being done on phone: calls, texting, messaging (whatsapp, messenger lite), looking up internet, occasional remote desktop. 8-9hr day at work. Some messaging, calls, texting at home but less than at work.
No games on phone - I have a busy job and I have a PC, PS4 and WiiU.
Performance
Superstock has very good performance. Absolutely no lags. UI feels smooth and fluid. I don't game however.
Notorious feels smooth and snappy despite being quite underclocked. Developer sped up the boot animation fps. Maybe it's in my head (and therefore insignificant if any), but possibly a bit slower to start apps. No lags however. Again, I don't game on the phone.
Battery
Superstock
Very good battery. A fair bit better than stock. I could lose between 1-4% overnight (6-9hr sleep). Never bothered measuring SOT but the phone lost on average ~20-25% per day moderate use as outlined above.
Notorious
Excellent battery. On my off days, I found that notorious enters deep sleep faster than superstock leading to less idle drain. It also seems to drain battery slower when screen on. Would lose 1-3% over a 6-9hr sleep. Average day would use up about 12-17% battery moderate use as outlined above.
Special features
Superstock is a plain kernel that just works out of the box. Not many modding opportunities - can adjust clock speed within the stock range. No voltage change. Can use the 3 basic governors. conservative, interactive (stock), on demand. Can change IO scheduler and TCP congestion algorithm. Only notable feature is the safety net green. A few services disabled according to the developer, but that is about it.
Notorious is very customisable with mtweaks many governors to choose from (I only bother using interactive). Under/overvolt and under/overclock avaliable for CPUs. Under/overvolt and under/overclock available for GPU. Boeffla kernel wake lock blockers. IO scheduler change, TCP algorithm change. I changed very few settings, but it is also commonly undervolted. On the thread, people liked to use bluactive, impulse and relaxed governors rather than interactive. With Notorious, I found that undervolting didnt really increase battery life much and gave me the increased paranoia of silent corruption/ instability. I change the TCP and IO so that it theoretically optimises my user experience. Realistically, I found no difference compared to stock and it was more for my obssesive compulsive side.
Verdict
For a non-gamer like me who uses the phone for calling, messaging, internet, video, music notorious provides more than adequate performance with greater battery savings than superstock.
Superstock I'd imagine to have much greater performance under a big load. It was subjectively more responsive and faster when doing my low power tasks.
At the end if the day both were much better than stock for me in terms of battery. I'd say that Superstock would be more for performance and Notorious would be more for battery saving. Any questions or comments, ask away!
Click to expand...
Click to collapse
Hello,
Thank you for the very detailed review. :good:
May I ask how did you flash the notorius kernel ?
Did you installed the Superman ROM and then reflash the kernel over it ?
Thank you. :fingers-crossed:
Tqhao94 said:
Hello,
Thank you for the very detailed review. :good:
May I ask how did you flash the notorius kernel ?
Did you installed the Superman ROM and then reflash the kernel over it ?
Thank you. :fingers-crossed:
Click to expand...
Click to collapse
Glad I'ts helping someone choose, cos I was very on and off abuot which one i wanted until i actually did the tests.
This is not the right forum to post this lol. This is meant to be about kernel reviews. The notorious kernel forum itself however isnt very clear.
It's just simply installing via twrp. dont forget to clear davlik/art cache after installation. Also, you need to flash root afterwards. I recommend you dont flash the root that the kernel comes with and to flash the root separately as there have been some bugs regarding that and also so that you can get the most up to date root.
Eggleston11 said:
Glad I'ts helping someone choose, cos I was very on and off abuot which one i wanted until i actually did the tests.
This is not the right forum to post this lol. This is meant to be about kernel reviews. The notorious kernel forum itself however isnt very clear.
It's just simply installing via twrp. dont forget to clear davlik/art cache after installation. Also, you need to flash root afterwards. I recommend you dont flash the root that the kernel comes with and to flash the root separately as there have been some bugs regarding that and also so that you can get the most up to date root.
Click to expand...
Click to collapse
That discussion was very helping but the question the i have is that i am a heavy gamer and most of my battery drain is caused due to games... which one would u suggest for better gaming battery life from the above mentioned?
Xial Xahab said:
That discussion was very helping but the question the i have is that i am a heavy gamer and most of my battery drain is caused due to games... which one would u suggest for better gaming battery life from the above mentioned?
Click to expand...
Click to collapse
Generally speaking this depends on the performance you need. If you can get your games to run sufficiently fast underclocked like on notorious, it will improve your battery life more just like it does in general. If it's too slow that way you'll have to see if super helps over stock. You could also try notorious and up the clock to more stock values but test out undervolting on it (as mentioned that does pose some risk) and see if your particular chip can be stable at a nice undervolt. Undervolting at high clocks can potentially save you a lot of battery life, but it depends on whether your chip is a "good" one or not.
Flandry said:
Generally speaking this depends on the performance you need. If you can get your games to run sufficiently fast underclocked like on notorious, it will improve your battery life more just like it does in general. If it's too slow that way you'll have to see if super helps over stock. You could also try notorious and up the clock to more stock values but test out undervolting on it (as mentioned that does pose some risk) and see if your particular chip can be stable at a nice undervolt. Undervolting at high clocks can potentially save you a lot of battery life, but it depends on whether your chip is a "good" one or not.
Click to expand...
Click to collapse
Yep agreed => try games out on notorious. if they can work well on low clock speed, then keep it. Trying speeds between stock and notorious can work if the games are too laggy. Stock values may be necessary depending on what games you are using.
Undervolt may also help to improve performance while at lower clock speeds a less heat generated. Less voltage does also theoretically mean less power used. I have found the difference in battery life and heat with underclock to be quite insignificant. People calculate it to be 2-5% less power used. Given notorious already uses less than 1% per hour on average use for me. It means i'll be saving at best 5% of 1% so 0.02% per hour. Not much power saved and not worth in my opinion given the side effects.
Eggleston11 said:
Undervolt may also help to improve performance while at lower clock speeds a less heat generated. Less voltage does also theoretically mean less power used. I have found the difference in battery life and heat with underclock to be quite insignificant. People calculate it to be 2-5% less power used. Given notorious already uses less than 1% per hour on average use for me. It means i'll be saving at best 5% of 1% so 0.02% per hour. Not much power saved and not worth in my opinion given the side effects.
Click to expand...
Click to collapse
The key is to undervolt during gaming, not idle. Undervolt can give exponentially more power savings at high clock speed. I agree it's not going to help for low clock speed and isn't usually worth the risk to corruption. With my Nokia N900 (back when you actually had to milk out all the MHz you could just to get 3D games on a phone, or in my case MAMEing arcades i could greatly increase gaming time when i dropped the volts for the highest CPU frequencies.
I appreciate your careful review of the two kernels. I'm still trying to figure out the ROM jungle for my new S7 Edge. Are these kernel and ROMs you are talking about snapdragon compatible or it this thread purely in exynos territory?
Flandry said:
The key is to undervolt during gaming, not idle. Undervolt can give exponentially more power savings at high clock speed. I agree it's not going to help for low clock speed and isn't usually worth the risk to corruption. With my Nokia N900 (back when you actually had to milk out all the MHz you could just to get 3D games on a phone, or in my case MAMEing arcades i could greatly increase gaming time when i dropped the volts for the highest CPU frequencies.
I appreciate your careful review of the two kernels. I'm still trying to figure out the ROM jungle for my new S7 Edge. Are these kernel and ROMs you are talking about snapdragon compatible or it this thread purely in exynos territory?
Click to expand...
Click to collapse
Agreed that the ~5% savings would translate to a greater amount of power saved during gaming in theory. I dont personally game on my phone, so your experience on this is better than mine haha.
I have the G935F. As far as I understand these kernels are for Exynos only. Good luck if you are searching for a good development scene with the snapdragon version. There are a few ROMs and Kernels i think. I have no idea about quality.