yashsingh1/xdaforums huggingface dataset:
[T-Mobile myTouch 4G Slide] yogi2010:
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):

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):

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!
[T-Mobile myTouch 4G Slide] yogi2010:
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.
[T-Mobile myTouch 4G Slide] daniel60104:
Yay, kernel development!

Have you guys tried to push past 1.5ghz?
[T-Mobile myTouch 4G Slide] yogi2010:
yeah, i think Blue is gonna work on that next :)
[T-Mobile myTouch 4G Slide] dung8604:
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.
[T-Mobile myTouch 4G Slide] Blue6IX:
...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.
[T-Mobile myTouch 4G Slide] 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.
[T-Mobile myTouch 4G Slide] dung8604:
View attachment 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.
[T-Mobile myTouch 4G Slide] 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.
[T-Mobile myTouch 4G Slide] 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.
[T-Mobile myTouch 4G Slide] 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.
[T-Mobile myTouch 4G Slide] 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.
[T-Mobile myTouch 4G Slide] yogi2010:
i PM'd you some info, until we get our gits set up :)
[T-Mobile myTouch 4G Slide] dung8604:
Thank you, I saw that earlier. I must say, this is looking very promising:

View attachment 933822
[T-Mobile myTouch 4G Slide] nl1bzw:
Can 2 way call recording also be added to the kernel?
[T-Mobile myTouch 4G Slide] KrnlPanic:
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!
[T-Mobile myTouch 4G Slide] Blue6IX:
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.
[T-Mobile myTouch 4G Slide] Fuzi0719:
So really there are no alternative kernels for a 1.55.531.3 based ROM?
[T-Mobile myTouch 4G Slide] yogi2010:
Not yet I don't think. I've tried taking the zImage from one of our boot images here, and packing it up with the ramdisk from the OTA kernel, and it comes VERY close to booting up, but it quits right before the lockscreen is supposed to show up after the boot animation. Something can probably modified for it to work, but I personally don't know what it is yet.
[T-Mobile myTouch 4G Slide] Blue6IX:
Check post 3 with the 1.5 overclock and I edited in a snapshot of a spreadsheet page comparing stock to my edits, and will get tables for the others out.

We're trying to get the information put out, and still need to get this in git, but while we're setting it all up thanks for being patient.

This scaling table makes much more sense in using the processor given how it works and utilizes the various options available to it.
[T-Mobile myTouch 4G Slide] AgentCherryColla:
Hey Blue :D My Wife just got a Doubleshot, she had an iPhone but it just exploded! (After Market Battery blew while charging). She'd currently running MIUI by TB. Now I flashed the 6% UV Kernel from this thread, and it worked! Wifi, data, calling, etc. But here's an issue I saw, no hardware keyboard. The lights work, but you can only use the soft keyboard. I was wondering why the HW KB wont work. The unity kernel allows it to work. I also tested your kernel on CM7, and it works fine. But same KB issue.

This could be pretty sweet for those who want to run MIUI/CM7 with good battery life.
[T-Mobile myTouch 4G Slide] Blue6IX:
Jeez! Hope she is okay!

Miui and I believe CM7 use different libs or something like that for the hardware keyboard - so the kernel code won't match up with those ROMs.

The kernel installer for these kernels removes and then puts in place it's own wifi module, so that shouldn't be a problem and i'm glad to hear it isn't for other ROMs beyond what's been tested.

I'm sure we could work something out to get the hardware keyboard working in the manner of a second flashable that you'd use depending on the ROM to fix things like that, but that's a research and maintenance nightmare from a dev standpoint.

The only ROM I use is my own, sometimes the stock for testing, but I have basically dialup speeds at my house and so don't actually have any of these other ROMs in my possession...

I just got in and want to keep working on the frequency tables so I can get the 1.7 kernel out - the performance on it is staggering ...

I firmly believe that the doubleshot hits it's design sweet-spot at 1.7GHz (1.728 more precisely) and I haven't gotten anywhere near the level of wow out of it at anything else - also generates less heat (on FPSE at full blast output to tv) then doing the same thing at 1.5 i've noticed.

But, I did play with some of the base multiplications it uses on the 1.7 kernel, and there is a mathematical harmony you can't get at any other frequency besides 1728000 that resonates with the heart of the scorpion architecture. The performance I am getting out of it blew away even my lofty expectations after looking at all the math I did to figure it out.

( ... of course - nothing is free and it comes at a cost...namely, battery life. Running at 1.7 flat out will murder your battery. I suggest using setcpu to keep it's max something much less unless you are playing a game or something heavy.)

I have too big of a jump from one frequency to another around 1.2 on the 1.7 kernel i'm playing with and i'm seeing a performance loss as it jumps around the CPU tables trying to deal with that (seeing in logs, couldn't notice in use) and so I want to get that worked out before posting it.

Once I finish with the frequency tables on the 1.7 i'll go back and re-scale the 1.5 one i've got up a little more nicely.

...after that, my mission is to add ALL the legal & valid frequencies to each and expand the table, while tinkering with the voltages to make it juuust right. (This will mostly be yogi's work)

There are many other issues in the kernel to be resolved, and i'd like to get the CPU stuff mainly out of the way and handled (read:done) so I can drop it and move on to other things with this project.

Tinkering with the voltages for performance is a long-term trial and error process. Virtually everything else about the CPU tables and scaling can be worked out mathematically up front, but work keeps getting in the way so I can only get so much computed and coded at once.
[T-Mobile myTouch 4G Slide] dung8604:
So the title says 03/10, what was updated on that day? Did I miss something?
[T-Mobile myTouch 4G Slide] SpaceSpeed:
Hmm, I suppose I could downgrade my current ROM back to 1.28.531.x but I'd rather not. I've dabbled with CyanogenMod, Virtuous and Pyro, but I always find myself coming back to the stock experience (debloated and deodexed of course). Try not to hate :o

Based on Yogi's comments, it sounds like there are some significant stumbling blocks to getting a 1.55.531.3 compliance OC / UV kernal up and running :(

Let me know if there is anything I can do (beta testing, etc) for a 1.55 kernal if someone has another whack at it.
[T-Mobile myTouch 4G Slide] Coug76:
He added a kernel at the bottom of post three.

Hastily spouted for your befuddlement.
[T-Mobile myTouch 4G Slide] edwardng:
voodoo

Any future development or support for voodoo sound control/kernel on this kernel for mytouch 4g slide? *anticipating*
[T-Mobile myTouch 4G Slide] Blue6IX:
-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.

Here is the table posted in 5:

You can see that I calculated all of the available frequencies up to 2.2GHz - but they are not available.

The 1.7 kernel that was just added is capped at 1.7 (1728000) but moving beyond that there are the frequencies that would be used - so that information may be helpful to someone someday, and to me when I push this machine to it's limits in the future.

I figured since I was working the numbers on the calculator to come up with the frequencies in range, I might as well compute the ones out of range too.

Eventually the kernels at different speeds will be merged back into one, but for now it's easier for testing to have differing branches of code from the development side, hence more then one kernel.

Now that we have the CPU frequencies tables computed and coded, time to optimize the L2 cache tables better and continue the trial-and-error process of undervolting.

Once we get more info on what's good for UV, we can start pushing past 1.7GHz.

(I don't recommend running above 1.7, qualcomm doesn't recommend above 1.5, and HTC doesn't recommend above 1.2)

(I also need to set up git so I won't have to post as much in the threads, but it's been hectic around here and the little bit of time I get at the pc has been on progress, and not taking in new things - soon guys, and thanks for the patience on this!)
[T-Mobile myTouch 4G Slide] Blue6IX:
Voltage

Okay, I ran out of time before I could get the voltage tables put together like the CPU frequency tables above - over the rest of the weekend i'll get that finished.

I did want people to know what voltages they were running so they weren't worried about burning out their chip.

We have found HTC to be overly generous on the voltage they were providing for the chip, so it runs fine at 1.2 volts at the 1.5GHz speed. I've been running that since about when we got the kernel code and it's been fine.

HTC originally had the 1.5GHz frequency penciled in at 1.25 volts, so we will make an assumption here that that is still within safe voltage ranges.

Since it runs so well at 1.2 volts even at the 1.5GHz frequency, i've used that 1.25 volts HTC had in there for the 1.7GHz frequency instead, and also for the 1.674GHz frequency right below it.

All other stock frequencies are at stock voltages in the kernels, and new frequencies added kept the stock levels of the last known voltage below it.

Even through bumping the CPU all the way up to 1.7GHz, we were able to stay within the voltages provided to us prior to starting, without having to increase voltage in any cases!

From here we really start in on systematic undervolt, to find out what we can get away with and still maintain the level of performance we demand out of the chip.

I'd love to use the least amount of juice possible to get the job done, but not interested in sacrificing performance to do so. The balance of power invested to do the work in fewer cycles versus power invested to keep the work in play is our focus at this point.
[T-Mobile myTouch 4G Slide] AgentCherryColla:
Your doing a lot of great work. This info is going to be very useful when others decide to make OC kernels.
[T-Mobile myTouch 4G Slide] nemesis93:
We've got a 1.7ghz kernel!!! This is so exciting I'm gonna flash bulletproof just to try it out!

Great work guys I really appreciate it!
[T-Mobile myTouch 4G Slide] levp:
TUN.ko?

Would it be possible to get a TUN.ko module compatible with either of these kernels?

TYVM!
[T-Mobile myTouch 4G Slide] CoNsPiRiSiZe:
What does that do exactly?

Typed by ---- oh wait! I'm schizophrenic!
[T-Mobile myTouch 4G Slide] levp:
It is required for OpenVPN to work.

http://vpnblog.info/android-openvpn-strongvpn.html

"You need properly configured TUN driver, OpenVPN will connect to the VPN but you will not be able to actually use. Driver file tun.ko will vary depending on your phone and kernel. The correct tun.ko can only be provided by the person/group who provided you your Android kernel"
[T-Mobile myTouch 4G Slide] Some_dude36:
Which is the best kernel for max battery life but still stable ? stock 1.5 or 1.7?
[T-Mobile myTouch 4G Slide] daswerk:
I have been running the 1.5 @ 192/1512 for awhile - lasts all day for me. (With an Anker battery)
[T-Mobile myTouch 4G Slide] nemesis93:
So I've been running the 1.7ghz kernel for about 3 days and the only problem I've found is 2 random reboots that require a battery pull cause of the bootloop ): . Other than that is perfect.

I might try out yogis uv kernel after this week and hopefully I don't get any random reboots.
[T-Mobile myTouch 4G Slide] Blue6IX:
I've been noticing that too now that i've opened up the full table of options, so this:

... is maybe more valid then I had thought.

I am having the same results with the 1.5 kernel with the open table.

So as soon as I get the chance I will re-scale the options back to the number that were originally available, eliminating entries based on what i've learned tracking how often the processor uses certain frequencies. The ones rarely used will get axed, but we have to keep some we don't use often for other things like USB and such.

918 and 972 are the most used mid-range frequencies when it jumps from high to low, so keeping those will be more important then most other frequencies.

So tonight, or tomorrow i'll recompile them with a scaled back number of entries to the same number that were available in the stock kernel, just in a wider range of frequencies.

I wasn't having issues with it when the CPU table was the same size as stock, but have been now that it's larger - so i'm thinking this is the source of the issue and the best way to test to start is to do this.

This is an exploratory works in progress, so we are learning as we go. Figuring out where and why we get problems will help make the end result better for us all and others who come to this in the future.
[T-Mobile myTouch 4G Slide] Blue6IX:
Things are going to get a bit chaotic real quick if we make a bunch of kernels with different features - it's a lot more to track and troubleshoot.

I'd like to get the CPU table set and stable, tested and working well before adding other things.

I think before I switch gears and start working on undervolt I could go ahead and enact these changes before moving on, as well as some others that have been mentioned and even more that i've wanted to change.

Given that i'll be making new versions but keeping the old versions available so people can switch back and forth to test things out it'll become too convoluted of a project for me to tackle the way i'm approaching it at this phase. Once CPU tables are set we can explore other options is the way I see it.