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
Related
I have my Sensation set to 1.5Ghz and it works perfectly. The only thing is that it's getting a little hot (which is expected btw). It's currently fixed at 42C. 1.5Ghz is great but is it really that necessary? Should I just OC it to 1.3Ghz? I'm trying to find a nice temp base.
monkey hung said:
I have my Sensation set to 1.5Ghz and it works perfectly. The only thing is that it's getting a little hot (which is expected btw). It's currently fixed at 42C. 1.5Ghz is great but is it really that necessary? Should I just OC it to 1.3Ghz? I'm trying to find a nice temp base.
Click to expand...
Click to collapse
To answer your question, each device will have a differing operational ceiling depending on the quality of the SoC, soldering, silk-screening etc. They aren't all created equal. If 1.5GHz works fine for you, stick with it I see OC kernels pushing to 1.8GHz now.
Naturally the higher you go the hotter your SoC will run, so I'd play around and find the point where you gain some performance, but negligible heat over stock. Heat will kill not only your SoC, but your battery as well.
I'm only going from personal experience, but I've never found an OC to be worth it in terms of an actual, real-life performance increase, on any device. It looks good in benchmarks, but I'd rather have a phone that was smooth as butter in day-to-day operation than a jerky piece of sh*t that gets 10,000 in Quadrant YMMV of course!
The heat stress and battery drainage costs, plus stability issues, outweigh the positives for me.
How can I reset my CPU back to stock then?
monkey hung said:
How can I reset my CPU back to stock then?
Click to expand...
Click to collapse
Most of the Sensation ROMs feature what's called an OC Daemon.
This is pretty much an automatic overclocker of sorts. It can change your clock ceiling/floor automatically depending on load. Read a bit more about it here.
If you have something like SetCPU installed, the Daemon is redundant, giving you manual control over your clocks. The easiest way to return to 'stock' frequencies would be to simply delete SetCPU and allow the Daemon to do it's thing
Well I uninstalled it and I have LeeDroid. How do I find this "daemon"? Where would it be located? What do I do I'm a noob
monkey hung said:
Well I uninstalled it and I have LeeDroid. How do I find this "daemon"? Where would it be located? What do I do I'm a noob
Click to expand...
Click to collapse
I couldn't see whether the daemon in included on LeeDroid, or whether LeeDroid has actually just modified the frequency tables (list of supported frequencies) to allow for the ~1730MHz ceiling. If the daemon is there, it'll already be working for you - you don't see it
I don't believe it's something you can just download and tack on. I think you'd have to be running a supported ROM. You may need to dig a little deeper into the LeeDroid thread and do some reading, or perhaps retitle this thread to ask 'Does LeeDroid include the OC Daemon' or something similar.
Sorry I can't be more help, I'm a devout Android Revolution HD supporter myself, although I am running the UNITY kernel.
Good luck mate!
personally I can't see the need to over clock, given that all software is probably written for devices currently in use, I do not know of any dual core 1.5 or higher phones, so why oc ?
I agree , I would rather have a fast stable phone, than some jerky fc piece of ****e that gets 10000 jiggawatts in a benchmark, and that can cook my crumpets..................... on second thoughts, I do like my crumpets.
This thread shows the results of some benchmarks of the Android OS (using a Nexus S) where certain parameters affecting performance have been isolated to the greatest extent and then compared statistically.
Background
I teach mathematics, and also used to be a professional sound engineer.
Some of my work on measuring battery drain was published on the XDA portal here however since then further studies were conducted, revealing critical flaws in my original test setup.
Although I believe some of my finding may be generalised to other devices, please bear in mind that my device is a Nexus S, and has its own peculiarities. I have attempted to edit out findings which I believe may be specific to the Nexus S, but I have linked to the original thread in case you wish to go exploring further results, or get an overview of my methodologies, which are usually in the second post.
Please feel free to post or PM with any queries, and I am more than happy to help if you want to apply my techniques to your own device.
Results
Over my time here in XDA I've built up a few studies on the Nexus S.
Here are the links. There are summaries in each thread in the first and second (and sometimes third) posts of the main findings, but I've done some very quick and minimal overviews here also.
ICS ROM Benchmarks: this thread
-Freely available benchmark programs were used to determine which ROMs had the best performance. Among the top six were an AOSP ROM with some CM9 parts, MIUI, and Stock, all within about 1% of each other. My conclusion was that the gingerbread tweaks we all knew and loved didn't improve performance with ICS, and in some cases, enthusiastic young developers were throwing together incompatible tweaks that hurt performance.
Battery Drain Benchmarks: this thread
#1 - With screen on, the slowest processor step saves the most power (duh... )
#2 - Regardless of your choice of governor, even with extreme undervolting, you are not going to be able to increase your battery life by more than 2%. (Click here for explanation.)
For the instability introduced by UV, it seems a 2% increase in battery life isn't really worth it! REMEMBER rebooting uses so much power, a single one would more than undo any savings made by UV.
Also, undervolting seems to cause more reboots when the battery is running low. This makes sense, as the battery runs low it loses some of its voltage (which shouldn't be confused with remaining power capacity).
#4 - This is one point that everyone ought to know, but I'm including because many people seem to believe in myths: if the screen is off, and the CPU is not active, neither deep idle nor UV will have any impact on battery life.
#6 - If you have an amoled display, black saves a great deal of power. After that, red. If you have a black and red theme, this is saving you power!
#9 - For amoled displays, Kernels higher FPS mods will cause the screen to drain about more power. For instance, on the Nexus S, 65 fps drained 10% more power than 56 fps. Also, 50 fps saved about 7% power compared to 56 fps.
#11 - If you've got no reception, you might as well be in airplane mode, because searching for reception also eats battery.
#12 - If your phone can't handle OC (or UV for that matter) it's because components in general are built to cost, which means factoring in tolerances, and every chip is made as cheaply as possible within the specified tolerances. Outside of those tolerances, whether your chip can cope or not is unfortunately down to the whether you got lucky with the individual device that dropped off the manufacturing line.
ARM document on A8 fault tolerance: http://infocenter.arm.com/help/index.../Babhjhag.html
In fact I measured how UV in particular can cause errors, and saw in action the A8 using MORE power to correct the errors.
CPU Governors and I/O Schedulers: this thread
-Interestingly, CFQ generally performs very well, and deadline. Most custom kernel developers in the Nexus S section recommend a version of deadline that has been tweaked for flash storage. In one of my unpublished benchmarks deadline performed slightly better than CFQ.
Does SuperCharging work?: this thread
-This was just a short study to find out if this script is suitable for the Nexus S, but it turned out it had no effect, positive or negative. This script was probably more use on devices that had less memory. One benefit that remains is to 'bulletproof' the launcher.
Kernel Memory Allocators: this thread
-This is another short study for kernel developers to show that SLUB performs best.
I see a lot of overclocked kernel editions, and I am wonder could someone explane me, except extensive battery draining, instabillity and overheating of device, what is and is there any crucial positive point of overclocked kernels ?
Overclocked kernels are simply kernels whose speed limit had been raised above the stock speed.
That increases perrormans dramatically as is visible by different benchmarks utilities.
You are correct to assume that higher clock would require some extra voltage and that the phone will get hotter. But it is not always noticeable and is mostly depentant on the configuration.
The cpu clock is not always at the highest possible. Different governors define what speed should the cpu be at any time. If there's a lot of work the cpuspeed would increase and if it idles a lot it would decrease.
I love 3 oc kernels, Sebastian's, bricked and faux. They all have different philosophies but all are excelent, do not overheat and save gather.compared to stock though they allow higher cpu freqs.
I suggest you create a nandroid backup and try some of.there kernels. Give it atleast two days.before you make up your mind about it, and try another if you wish, till you find the one that is right for you.
Sent from my HTC Sensation using xda premium
I agree. I never see the point of over clocking. I always limit my processor to 1.18 or even 1.13 and never have any problems with overheating or poor battery life!
I used overclock kernels for a long time on my gs2. Its nearly the same like with a desktop CPU. Every CPU had it's own work range, many CPUs a
are even able to work with higher frequency but lower voltage than standard. This causes in higher speed with lower power consumption!
all you need is a kernel which allows individual voltage settings for each speed which you can set with setcpu.
BUT my opinion is that even the gs2 with 1,2 GHz dual core was faster than any Android app had needed, so the gs3 at all!
ATM I've setted the max frequency in setcpu to 600 mhz and I can't see any lags or missing speed...
So I guess many people are more looking for benchmarking than real practical advantage..
but undervolting is a real great thing for power hungry smartphones!
Gesendet von meinem GT-I9300 mit Tapatalk 2
You all right guys. That is why I asked myself that question because there is hard to find modded kernels with default speeds and all new goodies, because I have noticed even I "limit" overclocked kernel in my Hypersensation CM7 Cyanogen Settings, it happens that some kernels from time to time speeds up to overclocked value, even in settings they were limited, and that impact widespread device causes instabillity ( and corrensponding unpleasent situations of forced battery pulling).
Last good kernel what I find for my CM7 ( I don't like ICS) is Bricked_XE-1.6.beta7 and with this release of CM7 it seems that kernel edition further development stops.It runs on 1526 Mhz and I allways wonder why shouldn't it run "out of the box" on default speed...
Does anyone have suggestion link, (because I couldn't find it )for any CM7 modded kernel with all new goodies, but running on default Sensation XE Mhz speed ?
i have been using overclocked Kernels for a while now and rarely have any problems, the phone is quick, very quick and the battery drain is really not that different and that is running it at 1.72 with both cores permanently on
tin2404 said:
[...] because I have noticed even I "limit" overclocked kernel in my Hypersensation CM7 Cyanogen Settings, it happens that some kernels from time to time speeds up to overclocked value
Click to expand...
Click to collapse
This really should not happen. The maximum frequency for a governor is set through /sys pseudo-fs and (assuming the governor is not buggy) strictly followed. Maybe you have some leftover scripts somewhere messing with /sys?
tin2404 said:
( and corrensponding unpleasent situations of forced battery pulling).
Click to expand...
Click to collapse
And this should -- like already pointed out -- only be the case under heavy load. Normally, a sensible governor will only set frequencies necessary to satisfy the current load.
You may have heard about how flashing a new ROM can improve your Android experience, but flashing a new kernel is one of the best ways to improve your phone's performance, battery life, and even add some saucy new features. Whether you know anything about either, here's what you need to know to make it happen.
What Is a Kernel?
A kernel in an operating system—in this case Android—is the component responsible for helping your applications communicate with your hardware. It manages the system resources, communicates with external devices when needed, and so on. Android uses a variation of the Linux kernel. A kernel is not the same as a ROM, even though you install them in mostly the same way. A ROM is a bit more all-encompassing. It's the operating system you use on your phone, the software your phone uses to get things done—the kernel is the bridge between that ROM and your hardware. All ROMs come with a kernel installed, but you can install a third-party one if you like—and that's what this post is about.
What a New Kernel Can Do For Your Phone
Flashing kernels isn't quite as talked about as flashing ROMs, but it can do a ton for your phone, namely in the way of battery life and performance—though it can also add extra features to your device, too. Here are some things to look for when choosing a new kernel.
Better Performance and Battery Life
This is the big change a new kernel can bring to your device. I'd separate these into two categories, but they're so intertwined that you really need to consider both when picking a kernel. There are a bunch of different kernel features that contribute to this:
Clock Speeds: In a very basic sense, higher clock speeds will improve performance on your phone. Flashing a new kernel allows you to overclock your phone, using higher clock speeds than the manufacturer intended. They can also let you reach lower clock speeds, so you can underclock your phone when you aren't using it, thus saving battery life. Your kernel will only give you the option to do so, however; if you want to overclock, you'll have to flash the kernel in question and then use something like SetCPU or CPU Tuner to tweak the clock speed.
Voltage: Higher clock speeds use up more battery on your phone because they require more voltage. However, some ROMs come with lower voltage limits, which means your phone will run just as fast, but use up less battery. Some will even overclock and undervolt your phone, though all of this comes at the expense of stability—if you notice that your phone goes into a boot loop, or reboots at random times, you'll want to either lower your clock speed or upgrade to a kernel with a higher voltage. Some ROMS have further sub-categories in this section, like Hybrid Adaptive Voltage Scaling (HAVS), which can be better for battery life (at the risk of stability) and Static Voltage Scaling (SVS), which keeps your phone at a steady voltage.
CPU Governors: Different kernels can support different CPU Governers, which manage the way your phone ramps up or down its clock speeds as you use it. There are a few different kinds you'll see, including Conservative, which focuses on battery life by ramping up your CPU very gradually when needed; Interactive, which focuses more on performance and smoothness by scaling up the CPU faster; InteractiveX, which is like Interactive but scales the CPU down when your screen is off (for better battery life); and Smartass, which is similar to Conservative but takes more factors into account when ramping up the CPU.
Task Scheduler: Kernels come with two different types of task schedulers: the Completely Fair Scheduler (CFS) and the Brain F**k Scheduler (BFS). CFS kernels are designed for regular phone use, like texting, web browsing, and otherwise multitasking apps on your phone. Most stock kernels are CFS kernels. BFS kernels focus more on whatever app is in the foreground, which is great for things like games but can be a bit laggier and a bit less stable.
These are the biggest features, but kernel developers add in all kinds of other tweaks to their kernels when possible, whether its introducing a more efficient file system, making the RAM more efficient, and so on. Again, they should list the tweaks in their description, so read up on the kernels for your specific device to learn more. I'd also recommend checking out XDA user mroneeyedboh's HTC Evo 4G kernel starter guide, from which much of this information comes.
Extra Features
Kernels can also add full features to your phone, or fix other issues that the manufacturer hasn't attended to yet. For example, while a lot of phones support Wi-Fi tethering out of the box, some—like the Motorola Droid—don't. If you find your phone isn't letting you tether using apps like Wi-Fi Tether, you might need to flash a new kernel that supports Wi-Fi tethering on your device. Kernels for Samsung phones can add support for a feature called Backlight Notification (BLN), which, coupled with an app, can turn your phone's buttons into notification lights.
Keep an eye out for features you don't want, too. For example, some HTC kernels come with a feature called Superior Battery Charging, or SBC, that can overcharge your battery for better life—but is likely to shorten your battery's life at best, or make it unstable at worst. I'd avoid kernels with this feature. You should also watch out for kernels that disable certain features of your phone—since some features are manufacturer-specific, you won't be able to get them in other ROMs or kernels. A good example of this is HDMI support on the EVO 4G.
Again, just make sure you research all the kernels available for your device, and know what you're getting yourself into before you flash. Most phones should have a large forum thread somewhere on XDA or RootzWiki that lists all the kernels available for their device. Make sure you choose a compatible one, too—the version of Android you're running determines what kernels you can use, so make sure you don't flash a Sense kernel on an AOSP ROM (like CyanogenMod), and make sure you don't flash a Froyo kernel on a Gingerbread phone—they won't play nicely together.
How to Flash a New Kernel
Once you've found a kernel you want to flash, download it to your device. It should be in ZIP format. Flashing a kernel is almost exactly like flashing a new ROM. You'll need to flash a new recovery to your phone, like ClockworkMod, which you can flash with ROM Manager. Put the ZIP file on your phone's SD card, then start up ROM Manager and go to "Install ROM from SD Card". Choose the kernel's ZIP file and continue. Note, however, that some kernels require that you flash them through your recovery mode instead of with ROM Manager—so once again, do your due diligence on its home page before you go a-flashin'.
The main difference between flashing a ROM and flashing a kernel is that you do not want to wipe your data. Wipe the Dalvik Cache only, and back up your ROM if desired (I highly recommend doing so, in case something goes wrong). Other than that, you should be golden. If you haven't flashed a ROM before, I recommend reading up on that first—but if you're familiar with that process, flashing a kernel shouldn't be a big shock to the system.
SOURCE - - - Lifehacker.com
Started from the bottom
Tha TechnoCrat said:
You may have heard about how flashing a new ROM can improve your Android experience, but flashing a new kernel is one of the best ways to improve your phone's performance, battery life, and even add some saucy new features. Whether you know anything about either, here's what you need to know to make it happen.
What Is a Kernel?
A kernel in an operating system—in this case Android—is the component responsible for helping your applications communicate with your hardware. It manages the system resources, communicates with external devices when needed, and so on. Android uses a variation of the Linux kernel. A kernel is not the same as a ROM, even though you install them in mostly the same way. A ROM is a bit more all-encompassing. It's the operating system you use on your phone, the software your phone uses to get things done—the kernel is the bridge between that ROM and your hardware. All ROMs come with a kernel installed, but you can install a third-party one if you like—and that's what this post is about.
What a New Kernel Can Do For Your Phone
Flashing kernels isn't quite as talked about as flashing ROMs, but it can do a ton for your phone, namely in the way of battery life and performance—though it can also add extra features to your device, too. Here are some things to look for when choosing a new kernel.
Better Performance and Battery Life
This is the big change a new kernel can bring to your device. I'd separate these into two categories, but they're so intertwined that you really need to consider both when picking a kernel. There are a bunch of different kernel features that contribute to this:
Clock Speeds: In a very basic sense, higher clock speeds will improve performance on your phone. Flashing a new kernel allows you to overclock your phone, using higher clock speeds than the manufacturer intended. They can also let you reach lower clock speeds, so you can underclock your phone when you aren't using it, thus saving battery life. Your kernel will only give you the option to do so, however; if you want to overclock, you'll have to flash the kernel in question and then use something like SetCPU or CPU Tuner to tweak the clock speed.
Voltage: Higher clock speeds use up more battery on your phone because they require more voltage. However, some ROMs come with lower voltage limits, which means your phone will run just as fast, but use up less battery. Some will even overclock and undervolt your phone, though all of this comes at the expense of stability—if you notice that your phone goes into a boot loop, or reboots at random times, you'll want to either lower your clock speed or upgrade to a kernel with a higher voltage. Some ROMS have further sub-categories in this section, like Hybrid Adaptive Voltage Scaling (HAVS), which can be better for battery life (at the risk of stability) and Static Voltage Scaling (SVS), which keeps your phone at a steady voltage.
CPU Governors: Different kernels can support different CPU Governers, which manage the way your phone ramps up or down its clock speeds as you use it. There are a few different kinds you'll see, including Conservative, which focuses on battery life by ramping up your CPU very gradually when needed; Interactive, which focuses more on performance and smoothness by scaling up the CPU faster; InteractiveX, which is like Interactive but scales the CPU down when your screen is off (for better battery life); and Smartass, which is similar to Conservative but takes more factors into account when ramping up the CPU.
Task Scheduler: Kernels come with two different types of task schedulers: the Completely Fair Scheduler (CFS) and the Brain F**k Scheduler (BFS). CFS kernels are designed for regular phone use, like texting, web browsing, and otherwise multitasking apps on your phone. Most stock kernels are CFS kernels. BFS kernels focus more on whatever app is in the foreground, which is great for things like games but can be a bit laggier and a bit less stable.
These are the biggest features, but kernel developers add in all kinds of other tweaks to their kernels when possible, whether its introducing a more efficient file system, making the RAM more efficient, and so on. Again, they should list the tweaks in their description, so read up on the kernels for your specific device to learn more. I'd also recommend checking out XDA user mroneeyedboh's HTC Evo 4G kernel starter guide, from which much of this information comes.
Extra Features
Kernels can also add full features to your phone, or fix other issues that the manufacturer hasn't attended to yet. For example, while a lot of phones support Wi-Fi tethering out of the box, some—like the Motorola Droid—don't. If you find your phone isn't letting you tether using apps like Wi-Fi Tether, you might need to flash a new kernel that supports Wi-Fi tethering on your device. Kernels for Samsung phones can add support for a feature called Backlight Notification (BLN), which, coupled with an app, can turn your phone's buttons into notification lights.
Keep an eye out for features you don't want, too. For example, some HTC kernels come with a feature called Superior Battery Charging, or SBC, that can overcharge your battery for better life—but is likely to shorten your battery's life at best, or make it unstable at worst. I'd avoid kernels with this feature. You should also watch out for kernels that disable certain features of your phone—since some features are manufacturer-specific, you won't be able to get them in other ROMs or kernels. A good example of this is HDMI support on the EVO 4G.
Again, just make sure you research all the kernels available for your device, and know what you're getting yourself into before you flash. Most phones should have a large forum thread somewhere on XDA or RootzWiki that lists all the kernels available for their device. Make sure you choose a compatible one, too—the version of Android you're running determines what kernels you can use, so make sure you don't flash a Sense kernel on an AOSP ROM (like CyanogenMod), and make sure you don't flash a Froyo kernel on a Gingerbread phone—they won't play nicely together.
How to Flash a New Kernel
Once you've found a kernel you want to flash, download it to your device. It should be in ZIP format. Flashing a kernel is almost exactly like flashing a new ROM. You'll need to flash a new recovery to your phone, like ClockworkMod, which you can flash with ROM Manager. Put the ZIP file on your phone's SD card, then start up ROM Manager and go to "Install ROM from SD Card". Choose the kernel's ZIP file and continue. Note, however, that some kernels require that you flash them through your recovery mode instead of with ROM Manager—so once again, do your due diligence on its home page before you go a-flashin'.
The main difference between flashing a ROM and flashing a kernel is that you do not want to wipe your data. Wipe the Dalvik Cache only, and back up your ROM if desired (I highly recommend doing so, in case something goes wrong). Other than that, you should be golden. If you haven't flashed a ROM before, I recommend reading up on that first—but if you're familiar with that process, flashing a kernel shouldn't be a big shock to the system.
SOURCE - - - Lifehacker.com
Started from the bottom
Click to expand...
Click to collapse
thanks for sharing :good:
hi..
thx a lot for useful info for me as newbie. i'd like to req. permission to copy your info to my personal note..
i'm appreciated of your kindness.
TQ
Thanks, great information
Send From Samsung Galaxy S4
muchas gracias
zaki aziz said:
hi..
thx a lot for useful info for me as newbie. i'd like to req. permission to copy your info to my personal note..
i'm appreciated of your kindness.
TQ
Click to expand...
Click to collapse
Yes you can copy.
Started from the bottom
tks it's usefful
do u recommand a kernel for best battery life?
i am using jammal rom and allucard kernel, but i only get 3460 scores and battery life is terrible. any tips?
Great info
Sent from my GT-I9500 using Tapatalk
Informative. Much appreciated.
245235568
There are plenty of apps in play store to disable wifi and 3G in order to optimize battery
i use zero lemon battery its great 7500 mAh lasts for days
kernel for best battery life?
Ive heard good things about talexop kernel
I also have zero lemon battery 7500 mAh I can get almost three days life on it without a charge
Sent from my SGH-I337M using Tapatalk
Hello .. after i instal an official lollipop using odin i notice that my battery mah drop from oroginal 2600mah to 2100mah i using many programs like aida64 and battery monitor widget and every program told me my battery is only 2100mah and i think the mah is reading from android kernel , i downgrade the phone back to kitkat 4.4.2 and the battery mah reading was correct and back again to 2600 so i think it was a mistake during the install of lollipop so i download the newer firmware available -I9515XXU1BOE3- and upgrade my firmware again but the problem come back again with wrong battery reading only 2100mah, i try to wipe the battery state and make calibration but nothing solved i downgrade the phone and upgrade it again and the problem appear every time ... could any one please help me how to solve this problem ... thanks in advance
hunter777 said:
Hello .. after i instal an official lollipop using odin i notice that my battery mah drop from oroginal 2600mah to 2100mah i using many programs like aida64 and battery monitor widget and every program told me my battery is only 2100mah and i think the mah is reading from android kernel , i downgrade the phone back to kitkat 4.4.2 and the battery mah reading was correct and back again to 2600 so i think it was a mistake during the install of lollipop so i download the newer firmware available -I9515XXU1BOE3- and upgrade my firmware again but the problem come back again with wrong battery reading only 2100mah, i try to wipe the battery state and make calibration but nothing solved i downgrade the phone and upgrade it again and the problem appear every time ... could any one please help me how to solve this problem ... thanks in advance
Click to expand...
Click to collapse
It's normal. It's just wrong reading the battery capacity in lollipop. But, actually it is 2600mAh. It doesn't matter.
Sent from my Galaxy S4
I found undervolting could save up to 25% battery on my Nexus 4. I dropped it by 100mv which sounds a lot, but the device ran just as stable for I'd say 99% of the time. The only time I ever had a problem was if I started to take burst photos on the camera. I actually looked at recompiling the Camera apk to ramp up the the voltage ever so slightly.
:::fajri13::: said:
It's normal. It's just wrong reading the battery capacity in lollipop. But, actually it is 2600mAh. It doesn't matter.
Sent from my Galaxy S4
Click to expand...
Click to collapse
thank you for your answer ... i want to know is this a common problem when upgrading to lollipop and if any one else face this problem with wrong mah battery capacity
hunter777 said:
thank you for your answer ... i want to know is this a common problem when upgrading to lollipop and if any one else face this problem with wrong mah battery capacity
Click to expand...
Click to collapse
Do not worry, it is not a common problem but I had this some months ago on a leaked TW ROM. The problem fixed itself when I flashed CM12.1.
There is no impact on battery life.
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.