Hey everyone. I realized today that my phone is one of the few that can handle almost all clock speeds (1.6GHz with Trinity VMax causes a reboot on setting it) so I decided to do some Quadrant tests and show you. My process was simple: Flash the kernel, boot, set the clock speed and run Quadrant until the scores stopped going up. All the tests were done on CyanogenMod7 nightly release 29. Here are my results:
Netarchy 1.4GHz BFS (7 tests)
2703, 2843, 3174, 3209, 3216, 3248, 3297
Netarchy 1.4GHz CFS (4 tests)
2775, 3248, 3276, 3308
Trinty Max 1.4GHz (3 tests)
2820, 3474, 3476
Trinty Max 1.6GHz (1 tests)
3891
Trinty VMax 1.4GHz (5 tests)
2854, 3227, 3525, 3550, 3694
Trinty VMax 1.5GHz (4 tests)
2819, 3416, 3667, 3773
PS: The only reboots suffered during these tests were when I set the clock speed to 1.6GHz on Trinity VMax.
I guess no one was interested in this. Mods can close.
I guess it goes to show that quadrant isn't really a good testing mechanism. The results are rather skewed. Although I do see the Trinity performing a bit better than netarchy under similar clocking speeds.
Sent from my Nexus S using XDA App
When I installed the Trinity Kernel v1.1 on my N/S my phone bugged out.
My phone can't go over 1.3 but yet to try the trinity kernels without facing difficulty although i did get 3500+ quadrant scores with 1.4 BFS.
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 All.
How is the battery life on the new rom ?
I have the 6.1.0 Rom and its killing my battery , any one has the same issue ?
Was trying to switch Kernel no luck ...
Honestly, best for you to judge for yourself since everyone's configurations differ.
Also, might be a bit early to tell since I don't think the ROM has even been released for a day which means most people may not have even used their phone enough to have an opinion.
biosize said:
Hello All.
How is the battery life on the new rom ?
I have the 6.1.0 Rom and its killing my battery , any one has the same issue ?
Was trying to switch Kernel no luck ...
Click to expand...
Click to collapse
Well, it all depends on how you configure the installation. What options did you choose?
For the one day that I have used Ordroid 7.0.1, I've been quite happy with the battery life.
SetCPU 1188 Max 192 min
governor ondemand
scheduler cfq
ordroid 6.1.0
Kernel 3.0.28-RCMIX
Base 11.69.3504.00P_11.22.3504.07_M
Build 1.78.401.2 CL58751
The ROM was released not very long ago. So there can´t be a right answer until now.
The Phone needs some "Complete empty" -> "Full charge" cycles to show the battery properly. A battery wipe is not the right solution.
Beside the CPU, GPU and stuff setting, lots of battery drain is caused by the synchronisation. So check if everything is really necessary.
Live background wallpaper need energy as well. So with some setup, you can bring your sensa to 1,5 days without surrender on anything.
With stock ROM it´s possible to get 2 days, but dont watch the screen to often ;-)
Well, I've figured that you can get maximum battery without much performance compromise if you configure it as:
Sweep2Wake {Yes (no capacitive backlight)} or {No}
ZRAM {No}
3DGPU Overclock {3DGPU OC disabled}
2DGPU Overclock {2DGPU OC disabled}
Governor {badass}
badass config {Balanced}
I/OScheduler {cfq}
Maxfreq {1566 MHz}
Minfreq {192 MHz}
Screen off max freq {486 MHz}
Keep the screen brightness at 35%. Switch off WiFi when not in use. Remove your HTC Sense account unless really required.
The lesser the number of accounts you have, the better it is.
Hope this helps!
Now its rebooting in a call
kgs1992 said:
Well, I've figured that you can get maximum battery without much performance compromise if you configure it as:
Sweep2Wake {Yes (no capacitive backlight)} or {No}
ZRAM {No}
3DGPU Overclock {3DGPU OC disabled}
2DGPU Overclock {2DGPU OC disabled}
Governor {badass}
badass config {Balanced}
I/OScheduler {cfq}
Maxfreq {1566 MHz}
Minfreq {192 MHz}
Screen off max freq {486 MHz}
Keep the screen brightness at 35%. Switch off WiFi when not in use. Remove your HTC Sense account unless really required.
The lesser the number of accounts you have, the better it is.
Hope this helps!
Click to expand...
Click to collapse
Thanks il do this when installing the new ROM
Any news guys ? Did any one tested the new rom for bat life ?
kgs1992 said:
Well, I've figured that you can get maximum battery without much performance compromise if you configure it as:
Sweep2Wake {Yes (no capacitive backlight)} or {No}
ZRAM {No}
3DGPU Overclock {3DGPU OC disabled}
2DGPU Overclock {2DGPU OC disabled}
Governor {badass}
badass config {Balanced}
I/OScheduler {cfq}
Maxfreq {1566 MHz}
Minfreq {192 MHz}
Screen off max freq {486 MHz}
Keep the screen brightness at 35%. Switch off WiFi when not in use. Remove your HTC Sense account unless really required.
The lesser the number of accounts you have, the better it is.
Hope this helps!
Click to expand...
Click to collapse
I configured the new ROM exactly like this .
Already did one full discharge .
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.
This kernel has a considerable difference in i/o speed, I was scoring ~5600 with row & now I'm ~9400. both with fsync enabled. My question is how much was this part oc by, and approximately how much risk does this carry?
current setup
maxkern v4 rc2; cdromi 4.6.9; [email protected] these settings
ubefuct said:
This kernel has a considerable difference in i/o speed, I was scoring ~5600 with row & now I'm ~9400. both with fsync enabled. My question is how much was this part oc by, and approximately how much risk does this carry?
current setup
maxkern v4 rc2; cdromi 4.6.9; [email protected] these settings
Click to expand...
Click to collapse
It is a big jump from 5600 to 9400 in Quadrant. You are experiencing the I/O speed of FSync disable even though you had it enable during the Rom installation. I believed that Max's kernel has a feature which is called a "Dynamic FSync", hoped that is what he calls it. The FSync is disable during an active usage and enable when it is sleeping. To answer your questions, the CPU specification for the tf700t is 1.6GHz on all cores. For the risk, it is depend on how much heat is building up around your CPU. Most of the commercial components are rated around 85 degree Celsius. If it is exceeded the Absolute Temp Rating, it will fry. You can use a temp app to monitor your temperature on your average usages. I hoped that it helps. By looking at your score report, your temperature is at least around 50C or more because your CPU frequency is starting to drop lower than the actual setting. :fingers-crossed:
Thanks, I believe your right about fsync. Just opened trickster mod and disabled fsync to see what it would score in quadrant seeing how i/o is already peaking in the 9200+. My i/o speed with disabled fsync is ~5600 .... so off is on and on is off? That is not cool
Update
Reflashed with _thats kernel v4; i/o deadline; data2sd mod(64gb sandisc class 10); fsync enabled; [email protected] gov.preformance (for test)
~7000 i/o :good: quadrant score attached ~1400 increase w/ data2sd mod
disabled fsync and did second test i/o ~9700 so toggle works as expected
I've been enjoying cdromi w/ data2sd mod _thats kernel v2(&3 mod with cdromi updated), after testing maxkern v4rc2 for a couple days (runs nice) I flashed to _thats kernel v4 & new data2sd mod. My tablet was for lack of a better word ...****ty before unlocking and slapping on a custom rom. Thanks @sbdags & @_that for making my tablet smooth and enjoyable
ubefuct said:
Reflashed with _thats kernel v4; i/o deadline; data2sd mod(64gb sandisc class 10); fsync enabled; [email protected] gov.preformance (for test)
~7000 i/o :good: quadrant score attached ~1400 increase w/ data2sd mod
disabled fsync and did second test i/o ~9700 so toggle works as expected
I've been enjoying cdromi w/ data2sd mod _thats kernel v2(&3 mod with cdromi updated), after testing maxkern v4rc2 for a couple days (runs nice) I flashed to _thats kernel v4 & new data2sd mod. My tablet was for lack of a better word ...****ty before unlocking and slapping on a custom rom. Thanks @sbdags & @_that for making my tablet smooth and enjoyable
Click to expand...
Click to collapse
Cromi x and _that combo give the most stable experiences in my opinion. You will be happy about that setup.