Any recent build of CM. They broke something for a week or two by changing healthd back in December, but they fixed it again since so many custom kernel users complained.
Running r395 with vanir (2/10). Straight butta. Hoping battery life will be up to par for me!
I've noticed this kernel doesn't have the "bells and whistles" of others. It seems straight forward and what you see is what you get. Is this what makes this kernel so great and have such a vast following? Franco wanted this kernel simple, but smooth?
Sent from my Galaxy Nexus using xda app-developers app
There are a lot of things Franco left out to keep it lean, vibration is a good example. Then he doesn't go for buzz words like Linero and O3 since Ezekeel showed any perceived improvement was basically placebo, so he uses Google's Android toolchain to avoid any issues.
But yeah, there are still a fair number of features under the hood. f.Ku or Trickster if you're poor. :good:
Plus if I remember right, he builds on an apple pc (darwin pc?), which isn't well supported by linaro lol
I did a little testing myself and found that a custom built toolchain made for cortex a9 with neon does actually improve performance some.
Franco may want to look into this to see if it's possible on Darwin toolchains, since you can configure the toolchain build for other cpus (like cortex a15 with neon, etc)
Haha yeah he moved on to an Ubuntu VM.
I mentioned those toolchains you and ak pointed me to but he said he'd still prefer Google's to avoid issues. My old laptop died but once I find a good deal I'm thinking I'll fire up Ubuntu myself and see what we get.
I can always clone his repo and compile with that toolchain, since my pc is already set up for building roms, kernels, toolchains, etc (basically everything you can build for android lol)
(I'm actually trying to compile a toolchain specifically optimized for the gnex right now lol)
That'd be awesome! I was going to try those final cflags you settled on too.
Probably need to grab the config.gz from proc though since the ones on Github didn't seem to correspond to what Franco was actually building (e.g. r394 not having ASRAM or modules even though I enabled them). :good:
Lol, not sure franco would work with those cflags. Its a pretty big jump from -O2 (which franco uses I believe) to -Ofast (which is even higher than -O3), and who knows about link time optimization and graphite optimizations
Latency - Download - Upload
1st run: 15ms - 10,75Mbps - 7,82Mbps
2nd run: 14ms - 10,84Mbps - 8,06Mbps
1st run: 13ms - 15,51Mbps - 6,73Mbps
2nd run: 13ms - 14,73Mbps - 8,51Mbps
1st run: 12ms - 10,38Mbps - 8,61Mbps
2nd run: 13ms - 10,78Mbps - 8,62Mbps
1st run: 11ms - 17,65Mbps - 8,30Mbps
2nd run: 13ms - 13,28Mbps - 8,29Mbps
1st run: 13ms - 10,76Mbps - 7,94Mbps
2nd run: 16ms - 14,42Mbps - 8,52Mbps
1st run: 14ms - 11,19Mbps - 7,44Mbps
2nd run: 14ms - 13,47Mbps - 7,56Mbps
1st run: 14ms - 13,24Mbps - 7,03Mbps
2nd run: 15ms - 10,85Mbps - 8,00Mbps
1st run: 14ms - 8,49Mbps - 6,62Mbps
2nd run: 14ms - 12,00Mbps - 7,07Mbps
1st run: 13ms - 9,58Mbps - 8,13Mbps
2nd run: 13ms - 8,50Mbps - 7,64Mbps
1st run: 18ms - 12,01Mbps - 8,73Mbps
2nd run: 14ms - 13,96Mbps - 8,23Mbps
1st run: 14ms - 14,90Mbps - 8,68Mbps
2nd run: 14ms - 13,44Mbps - 8,72Mbps
1st run: 14ms - 13,37Mbps - 8,28Mbps
2nd run: 17ms - 13,89Mbps - 8,14Mbps
1st run: 13ms - 12,93Mbps - 8,24Mbps
2nd run: 16ms - 13,97Mbps - 6,46Mbps
Just woken up and feel like my head is going to explode already this last 5 pages is crazy
I got these from that thread:
so it makes much sense, to make the min_sample_time as low as possible (?), but how low? what's the most appropriate sample time for battery and performance?
for the timer_rate, franco suggested 30k to consider the CPUs latency. What has it to do with the cpu's latency?
he also said min_sample_time doesn't have to be in multiple of timer_rate.
in my case, all my timers are in 20k, which works fine as of now. But i must be missing some things, because I just saw somebody post these values, and no detailed explanation for having them.
So to make the short hand easier, we kept it in that order and just said: 20000/50/40000/20000 became 20k/50/40k/20k became 2/5/4/2. Make sense?above_hispeed_delay: 20000
-above_hispeed_delay: Once speed is set to hispeed_freq, wait for this long before bumping speed higher in response to continued high load.
-go_hispeed_load: The CPU load at which to ramp to the intermediate "hi speed".
-min_sample_time: The minimum amount of time to spend at a frequency before we can ramp down.
-timer_rate: Sample rate for reevaluating cpu load when the system is not idle.
So Google's default is 10/5/6/2. Lower numbers are all better for performance except min_sample_time (there higher is faster). So our goal is to find a sweet spot.-above_hispeed_delay: higher = better battery, lower = better performance. (100k is default)
-go_hispeed_load:.......higher = better battery, lower = better performance. (50 is default)
-min_sample_time:......lower = better battery, higher = better performance. (60k is default)
-timer_rate:.................higher = better battery, lower = better performance. (20k is default)
Device: Galaxy Nexus
Max Frequency: 1305 MHz
Min Frequency: 384 MHz
Governor Tunables: a_h_d 15000 / g_h_l 95 / h_f 729600 Hz / m_s_t 45000 / t_r 15000 / i_b_f 1036800 Hz / t_l 85 / t_s 80000 / b_d 1000000
IO Scheduler: row
IO Scheduler Tunables: h_r_q 100 / r_r_q 75 / h_s_q 5 / r_s_q 4 / r_w_q 4 / l_r_q 3 / l_s_q 2 / r_i 15 / r_i_f 25
Read Ahead Buffer: 512; NR Requests: 512
TCP Congestion Avoidance Algorithm: westwood
Screen Off Max Frequency: 537 MHz
Color Multipliers: 230 235 340
RGB Gamma: -4 0 5
Trinity Contrast: -22; OMAP4 Gamma: 4; CAB: Disabled
Sent from franco.Kernel updater app:
1804mhz: 1425 mV
1728mhz: 1375 mV
1612mhz: 1325 mV
1536mhz: 1275 mV
1420mhz: 1225 mV
1305mhz: 1175 mV
1228mhz: 1125 mV
1036mhz: 1075 mV
729mhz: 925 mV
537mhz: 825 mV
384mhz: 775 mV
192mhz: 725 mV
430mhz: 1125 mV
332mhz: 1025 mV
266mhz: 925 mV
133mhz: 825 mV
512mhz: 1050 mV
384mhz: 975 mV
153mhz: 800 mV