Logging disabled in FKU?... Went to proc/ but no last ksmg. I'm confused. ...
Sent from my Galaxy Nexus
Logging disabled in FKU?... Went to proc/ but no last ksmg. I'm confused. ...
Sent from my Galaxy Nexus
About hot reboots: having them every now and then, every two days or something. Totally irrelevant when it happens: while listening music, or just when the phone is laying on the table with the screen on. Hopefully Google fixes this, not Franco related.
Sent from my Nexus 7 using Tapatalk HD
Great, let's put this clear for everybody
Max CPU frec: 1228
Min CPU frec: 384 (SOD avoiding)
Governor: Interactive
above_hispeed_delay: 15(k)
boost: don't touch
go_hispeed_load: 95
hispeed_freq: 0.7=729MHz
min_sample_time: 45(k)
time_rate: 15(k)
target_loads: 85
IO Scheduler: row
Read Ahead: 2048 (Can't be set through f.ku YET)
I have never had a reboot or sod using Franco especially the latest one. Never while running Xylon ROM and now over a month on Baked BB7.
The final winner tunables are running perfectly stable here on the GNex of my wife and on my own GNex.
No problems with 192/1228 :good:
I used a lot of gaming, listening to music, web browsing with Chrome, Tapatalk and Repligo Reader (PDFs). Performance and battery life are just amazing, no stability issues at all.
This is for the N7 but a similar test was done for the GN a few months back:
https://docs.google.com/spreadsheet/ccc?key=0AqRFyVFtJ0vodDF2V2FrYlVSTkhseV9DWjlaRkltRmc#gid=6
The GN results were similar. IO speed increases to a point with higher read_ahead_kb buffer values, then decreases again.
If I recall correctly, 2048 was found to be the sweet spot both times.
Edit: Wrong graph.. I'll try and find the one with 3072, etc.
Here we go, it's from M-Kernel, but results are similar:
https://docs.google.com/spreadsheet/ccc?key=0AqRFyVFtJ0vodHQ0Q3dqa2NWUXBzSG4tRHNqSmwzUFE#gid=6
I didn't know exactly which comment to quote since there have been dozens on comments with different tunables but why the just from 30 to 15? I haven't seen anything in between like 20 and 25. We might as well get it perfect instead of just dividing the numbers in half each time for a test, I've seen every other number be tested in increments of "5" except this one.Most people I've seen comment say that 95/85 is slightly laggier than 90/80, so I'm with Fen, I'd like to see if we can tell the difference with:
a) 15/90/0.7/45/15/80
b) 15/90/0.7/45/30/80
Hmm.. but you're right, maybe lowering the timer_rate to 15 allows us to use 95/85... okay, so:
c) 15/95/0.7/45/15/85
I can confirm that, with 2048 my phone gets laggy. With 256 it's faster in transitions. It's just how you use your phone what's good for you :good:
Sent from my Galaxy Nexus using Tapatalk 2
Benchmarks are one thing, real usage is another one.
With 2048 i feel my phone being sluggish in transitions. The best way to test that is scrolling the widget section very fast. Its simple a no go for me.
After that i tested some other values, and for now i found that 256 gives me the best transition in the Widget Section.
That's true, it depends from personal usage. Until Read Ahead becomes configurable via f.KU I use an init.d script to set it to my taste
I didn't know exactly which comment to quote since there have been dozens on comments with different tunables but why the just from 30 to 15? I haven't seen anything in between like 20 and 25. We might as well get it perfect instead of just dividing the numbers in half each time for a test, I've seen every other number be tested in increments of "5" except this one.
Franco believes that by setting the timer_rate to be the same thing as the CPU sample_rate (which is preset at 30000), then that will make the CPU more efficient at switching
From yellowdie's post
So that's why we've set that value to 30 or multiple of that e.g 30/2 = 15; 30*(3/2) = 45 and so on
Those are governor tunables and always have been available to tune on fku under frequencies/voltages > Governor controlGot cha, thanks! So these tunables have been implemented in the latest fku, correct?
Has anyone played with the new IO scheduler options?
I meant have the tunable values you guys been playing with for about a week been updated in the app? Are they the new default now?Those are governor tunables and always have been available to tune on fku under frequencies/voltages > Governor control
To make them the default values they should be updated on the kernel img not in the app. You can always mod them to your personal preferences thoughI meant have the tunable values you guys been playing with for about a week been updated in the app? Are they the new default now?
Just so people know, read ahead can be checked with:
cat /sys/block/mmcblk0/queue/read_ahead_kb
and set with:
echo 2048 > /sys/block/mmcblk0/queue/read_ahead_kb
You might have to su first. :good:
#!/system/bin/sh
echo 512 > /sys/block/mmcblk0/queue/read_ahead_kb
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