Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Thread Closed

[CLOSED]doubleshot kernel project OC/UV ( 03-17-2012 )

OP Blue6IX

5th March 2012, 08:52 PM   |  #11  
Senior Member
Thanks Meter: 71
 
919 posts
Join Date:Joined: Sep 2010
Click image for larger version

Name:	uploadfromtaptalk1330976981307.jpg
Views:	198
Size:	83.3 KB
ID:	933091

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.
5th March 2012, 09:32 PM   |  #12  
Account currently disabled
Flag Los Angeles, CA
Thanks Meter: 321
 
2,128 posts
Join Date:Joined: Dec 2010
More
Quote:
Originally Posted by dung8604

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.

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.
5th March 2012, 10:06 PM   |  #13  
Senior Member
Thanks Meter: 71
 
919 posts
Join Date:Joined: Sep 2010
Quote:
Originally Posted by yogi2010

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.

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.
5th March 2012, 10:27 PM   |  #14  
Blue6IX's Avatar
OP Senior Member
Thanks Meter: 1,137
 
1,771 posts
Join Date:Joined: May 2011
Donate to Me
Quote:
Originally Posted by dung8604

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.

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.
5th March 2012, 11:20 PM   |  #15  
Senior Member
Thanks Meter: 71
 
919 posts
Join Date:Joined: Sep 2010
Quote:
Originally Posted by Blue6IX

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.

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.
6th March 2012, 12:31 AM   |  #16  
Account currently disabled
Flag Los Angeles, CA
Thanks Meter: 321
 
2,128 posts
Join Date:Joined: Dec 2010
More
Quote:
Originally Posted by dung8604

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.

i PM'd you some info, until we get our gits set up
6th March 2012, 08:23 AM   |  #17  
Senior Member
Thanks Meter: 71
 
919 posts
Join Date:Joined: Sep 2010
Thank you, I saw that earlier. I must say, this is looking very promising:

Click image for larger version

Name:	uploadfromtaptalk1331018622045.jpg
Views:	159
Size:	66.8 KB
ID:	933822
The Following User Says Thank You to dung8604 For This Useful Post: [ View ]
6th March 2012, 02:15 PM   |  #18  
Junior Member
Thanks Meter: 0
 
17 posts
Join Date:Joined: May 2010
More
Can 2 way call recording also be added to the kernel?
8th March 2012, 09:24 AM   |  #19  
Member
Flag Roseville, MI
Thanks Meter: 5
 
98 posts
Join Date:Joined: Nov 2011
More
Quote:
Originally Posted by dung8604

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.

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!
8th March 2012, 06:15 PM   |  #20  
Blue6IX's Avatar
OP Senior Member
Thanks Meter: 1,137
 
1,771 posts
Join Date:Joined: May 2011
Donate to Me
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

Thread Closed Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes