- Dec 22, 2012
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
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: 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