[Hero, G2 Touch Android Development] RaduG:
Please take the time to read all the description. It is important!

What's new in RaKern-113?

I tweaked things here and there. It is now better to work with and much more stable. I've also discovered what was causing wlan not to work, and it is fixed. To be more specific:

- I've gone again a little bit into the scheduler and made some changes

- tweaked lowmemorykiller

- reduced the maximum frequency to 652MHz(from 691MHz), hopefully this will make the kernel compatible with more Heros

- patched smd_rpcrouter(see here why: http://xdaforums.com/showthread.php?t=878268 )

- created update.zip for any rom available

Why should you choose RaKern?(long story, good to read)

After some debates about the perfect cpu frequency governor for a battery powered device like ours(thank erasmux for that), I've decided to tune what I already have and go for the elegant way. That means using a tuned version of the ondemand governor while the screen is on, and then use the conservative governor when the screen is off. Here's the story:

The only major difference between the conservative and ondemand governor is that the ondemand governor switches to the highest frequency available when the cpu load is higher than the threshold set. Same thing when the load is lower than the min_threshold. The conservative governor takes all the available frequencies in the table and switches between them until the load is lower than the threshold. I've been thinking about it for quite a while and on our CPU I don't think this behavior is the best we can get.

Why? Well let's say we have 650MHz in our table as the maximum frequency. Staying on the same PLL, we would get something like: 176->352->518->537->556->576->595->614->633->652. Let's consider that the phone, while the screen is off, stays at 176 because there is no process that could put load on the cpu, which usually is true, depending on the user setup. When you unlock the screen, you might need a bit of power if you have an animated widget on the main screen. Let's consider that it also uses the internet to update its data and the cpu would be loaded under 80% only @576. In this case, the conservative governor will go from 176 to 576 like: 176-352-518-537-556-576. Remember that on each frequency the kernel will wait for a few us to check the load and then decide whether it needs to raise the frequency again or not, so it would take some time until the CPU can provide the power necessary to have a responsive phone. On the other hand, the ondemand governor would go straight to 652MHz(I forgot to mention that from 518MHz, all frequencies use the same voltage). But here comes the nice part(quote taken from the Ondemand governor data sheet):

So after jumping straight to 652MHz, it will go directly to 576. So instead of 5 steps, the ondemand governor only does two. Of course, in theory, the ondemand governor would be inferior in battery consumption, but in real life it is not so bad, and from my calculations it can even be better. Keep in mind that the latencies are pretty much the same on both governors. The conservative governor is just a modified ondemand.

The conservative governor would be excellent on a Snapdragon device(or any other cpu >1GHz), which can provide good performance at lower speeds, so you'd not have to jump to the highest frequency available. But on our Hero, the difference between 514 and 534 for example is unsignificant if the load is intense, so this basically causes latency.

On small loads, the power consumption with the conservative governor is much better than using the ondemand governor.

How is the governor changing done?

SetCPU. You need to create a SCREEN OFF PROFILE - 19MHz-352MHz with the CONSERVATIVE Governor. Here's how it should look like:

Here is the frequency table the kernel is using in its default setting:

As you have probably figured out, in screen-off mode the cpu can only go between 19-176-352. With the screen on, it has a wider choice, 352-518-556-576-614-652. I added more entries to the table(even though I always said this is not good) because I'm not using the default ondemand governor anymore. Now, if the load is >60%, it goes up. If the load is <70%, it goes down. IF the load is >90%, it goes to MAX and if the load is <20% it goes to MIN. This is very efficient and battery-friendly. It also changes very fast between steps, as I've done some other tweaks to improve latency.

Instructions:

Download the ZIP and flash it. Then, install SetCPU(if you don't have it already) and configure a profile as you've seen in the screenshot above. After that, you're good to go :).

The most important features are:

- Ondemand CPU governor improved for efficient frequency jumps and usage optimization

- dual-CPU governor based on screen state

- kernel level touch input filtering(Ninpo)

- EXT2/3/4 and FAT support

- IPv6 support, including GRE and IP multicasting(see more info below)... Mobile IPv6 should also work in a proper enviroment not anymore in 109 and 113, I will bring it back in the next version

- dalvik and swap optimizations

- battery life enhancements

- Fair scheduler tweaked for better performance

Message for users: RaKern-113 works brilliantly with ChocolateEclair 2.0.

IPv6 info(good to read, but not available in the current version):

I do not own an IPv6 capable router, so I can not say exactly how it works, but I can tell you how it should behave. From what I could see, in this configuration, the IPv6 implementation is similar to the one in Windows Vista/7. IPv4 and IPv6 work together, but IPv6 is preferred. If it can obtain a global unicast address, it will attept to communicate via IPv6. Also, support for IPSec and 6-to-4 tunneling is enabled.

Until a get a dual-stack router, I can only help you with theoretical information. Maybe fellows in Japan can give me a bit of help with this?

Filesystem info:

I've added support for EXT3/4 because I know some people might find using those FSs useful. But for the avreage user, I suggest sticking with EXT2 as its successors use more cpu juice.

Feel free to include this kernel in your ROM. All that I require is that you do not change the kernel name/version, and post a link to this thread in your ROM description. Other than that, it would also be good for the community if you'd share your changes here. Whichever leads to improvement is appreciated.

So... To the important part:

RaKern-113 for ALL ROMS

MD5 sum: 3a1d07e6a2bcbdcb39330477e877ac81

SOURCES

If you appreciate my work, please consider helping Santa buy some presents :)

​