lol. Its probably in the same place as that elusive pot of gold!
:-D
Holy!! Using r154 I'm getting much lower temps than I used to compared to m3 and r151-152.
+1 please 1.5 Ghz
Enviado desde mi Galaxy Nexus usando Tapatalk 2
I'm also seeing much lower temperatures than r152. Quite significant actually. Around 10 degrees lower on average while gaming and during idle. On 152 I was about 35 degrees idle and 50 degrees at high load, but with 154 my temperature coming out of idle was about 25 degrees and while benchmarking it never got above 45. Great stuff. These low temps mean good things for extreme overclocking .
(Lazy 192 - 1228 for 152 and 154)
---------- Post added at 08:28 PM ---------- Previous post was at 08:14 PM ----------
Having one other issue other than the custom undervolting problem. For some reason on 154 my SR voltage for the 384mhz slot is WAY higher than normal. Usually SR calibrates to 886mv, 1025mv, and 1050mv. Now its setting them to 886mv, 1025mv, and 1278mv.
From testing I've determined that I can run 384mhz GPU at 950mv before my framerate dropped, so 1050mv was a very reasonable calibration. 1278mv, however, is overkill.
If you want better battery get the 384gpu version. The difference isn't that significant but you will save more battery on the lower clocked gpu.Whats the difference betwen flashing the 300ghz gpu or the 512mhz gpu? Im using hotplug governor i just want good batt life
hi im king noob about kernel i used franco m3 and some nithigly before was greeat but never try to do uv, since i dont have the knowledge to do it, idk how much volt to drop and if just freq or core, if not too much to ask, i just want to see like a standard uv so i can star testing i know all cpu are different but at least a point where to star
/* SGX OPP1 - OPP50 */
OPP_INITIALIZER("gpu", "dpll_per_m7x2_ck", "core", true, 153600000, OMAP4460_VDD_CORE_OPP50_UV),
/* SGX OPP2 - OPP100 */
OPP_INITIALIZER("gpu", "dpll_per_m7x2_ck", "core", true, 307200000, OMAP4460_VDD_CORE_OPP100_UV),
/* SGX OPP3 - OPPOV */
#ifdef CONFIG_OMAP_GPU_EXTRA_OVERCLOCK
OPP_INITIALIZER("gpu", "dpll_per_m7x2_ck", "core", true, 512000000, OMAP4460_VDD_CORE_OPP100_OV_UV),
#else
OPP_INITIALIZER("gpu", "dpll_per_m7x2_ck", "core", true, 384000000, OMAP4460_VDD_CORE_OPP100_UV),
#endif
Found something interesting... if you look in voltage.h in mach-omap2 you can see that the phone is limited to a minimum voltage of 830mv. When I lowered this to 700, SmartReflex calibrates my 384mhz frequency to 770mv instead of 830mv. Running just as stable as before.
I fixed it. Now calibrates to 1038mv and working great.
In opp4xxx_data.c -
Basically changed the 384 to use OPP100_UV instead of OPP100_OV_UVCode:/* SGX OPP1 - OPP50 */ OPP_INITIALIZER("gpu", "dpll_per_m7x2_ck", "core", true, 153600000, OMAP4460_VDD_CORE_OPP50_UV), /* SGX OPP2 - OPP100 */ OPP_INITIALIZER("gpu", "dpll_per_m7x2_ck", "core", true, 307200000, OMAP4460_VDD_CORE_OPP100_UV), /* SGX OPP3 - OPPOV */ #ifdef CONFIG_OMAP_GPU_EXTRA_OVERCLOCK OPP_INITIALIZER("gpu", "dpll_per_m7x2_ck", "core", true, 512000000, OMAP4460_VDD_CORE_OPP100_OV_UV), #else OPP_INITIALIZER("gpu", "dpll_per_m7x2_ck", "core", true, 384000000, OMAP4460_VDD_CORE_OPP100_UV), #endif
Found something interesting... if you look in voltage.h in mach-omap2 you can see that the phone is limited to a minimum voltage of 830mv. When I lowered this to 700, SmartReflex calibrates my 384mhz frequency to 770mv instead of 830mv. Running just as stable as before.
I remember messing with the limits before and somethings fishy about decreasing the minimum limit, I just dont remember why.
Latency - Download - Upload
cubic:
1st run: 15ms - 10,75Mbps - 7,82Mbps
2nd run: 14ms - 10,84Mbps - 8,06Mbps
reno:
1st run: 13ms - 15,51Mbps - 6,73Mbps
2nd run: 13ms - 14,73Mbps - 8,51Mbps
bic:
1st run: 12ms - 10,38Mbps - 8,61Mbps
2nd run: 13ms - 10,78Mbps - 8,62Mbps
westwood:
1st run: 11ms - 17,65Mbps - 8,30Mbps
2nd run: 13ms - 13,28Mbps - 8,29Mbps
highspeed:
1st run: 13ms - 10,76Mbps - 7,94Mbps
2nd run: 16ms - 14,42Mbps - 8,52Mbps
hybla:
1st run: 14ms - 11,19Mbps - 7,44Mbps
2nd run: 14ms - 13,47Mbps - 7,56Mbps
htcp:
1st run: 14ms - 13,24Mbps - 7,03Mbps
2nd run: 15ms - 10,85Mbps - 8,00Mbps
vegas:
1st run: 14ms - 8,49Mbps - 6,62Mbps
2nd run: 14ms - 12,00Mbps - 7,07Mbps
veno:
1st run: 13ms - 9,58Mbps - 8,13Mbps
2nd run: 13ms - 8,50Mbps - 7,64Mbps
scalable:
1st run: 18ms - 12,01Mbps - 8,73Mbps
2nd run: 14ms - 13,96Mbps - 8,23Mbps
lp:
1st run: 14ms - 14,90Mbps - 8,68Mbps
2nd run: 14ms - 13,44Mbps - 8,72Mbps
yeah:
1st run: 14ms - 13,37Mbps - 8,28Mbps
2nd run: 17ms - 13,89Mbps - 8,14Mbps
illinois:
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
go_hispeed_load: 50
min_sample_time: 40000
timer_rate: 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: interactive
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:
https://play.google.com/store/apps/details?id=com.franco.kernel
mpu_voltages:
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
iva_voltages:
430mhz: 1125 mV
332mhz: 1025 mV
266mhz: 925 mV
133mhz: 825 mV
core_voltages:
512mhz: 1050 mV
384mhz: 975 mV
153mhz: 800 mV