Looks good, only thing is the iosched tunables tend to not work via init.d unless you put in a sleep to make the script wait to perform the commands, so I'd put them at the end, with a sleep 35 before. Really though, those are the defaults in r365 so you don't need to set them via init.d at all.
So far we think so, yeah. malaroth and franco are still tweaking some things but they're pretty much the same. boostpulse_duration was 80000 in r364, and is 100000 in r365, but we always have boost set to 0 (off) so it doesn't matter.
@malaroth, I have been running your ROW tweaks for a full 24 hour now, initial impression is pretty good, there's noticeable improvement, although deadline is still a tad bit smoother, it doesn't struggle as much when writing apps to /data for example, I can still smoothly type on the keyboard (It still stutters though) while Play Store is updating a bunch of apps, as well as installing large games. Of course that's just some very basic testing without enough sample for a proper result, I'll try it for a few more days and see how it goes.
I have a problem with the Franco Kernel. Time ago before applying an OTA I restored the original kernel and then I applied the update. But with Android 4.2.x even if I restore the original kernel saved before installing the Franco I always get an error when I apply the OTA? Any suggestions?
Thanks!
vbus_tuna_otg sounds like virtual bus for USB OTG devices. But for the life of me I can't figure out why this is my largest wakelock when I have yet to use OTG on my device. I wonder if its just constantly checking to see if there is a device attached. I wonder if we can tweak polling in the kernel to turn it down?
I have a problem with the Franco Kernel. Time ago before applying an OTA I restored the original kernel and then I applied the update. But with Android 4.2.x even if I restore the original kernel saved before installing the Franco I always get an error when I apply the OTA? Any suggestions?
Thanks!
With or without the comment, it still don't work. None of the command in the file. Should I put them in separate files?
Also I experienced some play store related freezes, and I noticed they happen ONLY when some app is updating/downloading and the screen is about to turn off. If I keep using the device everything is fine.
Did you create the file on PC and copy to phone? My only thought is you have the wrong end-of-line formatting.
#!/system/bin/sh
sleep 35
# chmod -R 755 /system/etc/init.d
echo "interactive" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 15000 > /sys/devices/system/cpu/cpufreq/interactive/above_hispeed_delay
echo 95 > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load
echo 729600 > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
echo 45000 > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time
echo 15000 > /sys/devices/system/cpu/cpufreq/interactive/timer_rate
echo 85 > /sys/devices/system/cpu/cpufreq/interactive/target_loads
echo "deadline" > /sys/block/mmcblk0/queue/scheduler
echo 512 > /sys/block/mmcblk0/queue/read_ahead_kb
sleep 2
echo "1900000000 1950000000 2150000000" > /sys/class/misc/colorcontrol/multiplier
echo 0 > /sys/class/backlight/s6e8aa0/acl_set
echo 5 > /sys/devices/platform/omapdss/manager0/gamma
echo -5 > /sys/module/panel_s6e8aa0/parameters/contrast
echo "-4 0 5" > /sys/class/misc/colorcontrol/v1_offset
sleep 2
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 1 > /sys/block/mmcblk0/queue/iosched/front_merges
echo 6 > /sys/block/mmcblk0/queue/iosched/writes_starved
echo 3500 > /sys/block/mmcblk0/queue/iosched/write_expire
echo 351 > /sys/block/mmcblk0/queue/iosched/read_expire
You need to read the error. Likely has nothing to do with the kernel if you properly reflashed stock.
I have spoken with another user and he told me about the "power.tuna.so" problem! I didn't know anything about this problem.
I think that the FK Updater should have a button to fix this!
Yes, the user have teached me how to fix the problem via terminal
Yup!! If you need more boot options, long press 'Power Off'.
The best thing is Wireless Display/Miracast is enabled. So it'll be fun to test once a Miracast certified adapter with official firmware is released. All in all, it runs great with Franco.
Sent from my Galaxy Nexus
Did you create the file on PC and copy to phone? My only thought is you have the wrong end-of-line formatting.D
I tried your script, but still no success. I think I'm giving up and waiting for Minco v6 with new franco kernel which should have those values as default
My first attempt was a file created on PC, then I tried writing it with OfficeSuite directly on the phone, but I had no better luck.
Is miracast enabled in r365? I am running it and can't find an option to enable wireless displays, I was hoping to test with the new f/w on the Netgear PTV3000 box.
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