yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy Nexus] reysonance:
Franco doesn't have any governor that use hotplugging.

And hotplug (a la InteractiveX) doesn't really affect battery that much anyway, since then main culprit of the battery drain is the stuff you do when you turn the screen on, instead the idle drain, which is already pretty low anyway.

And even governor like hotplugx, which has the ability to turn off cpu1 when the screen is on doesn't affect battery significantly, unless you use the device in such a way that cause the cpu to be able to scale down very frequently, like reading an eBook for long periods of time.

Anything other than that, hot plugging wouldn't help much.

EDIT: For clarification, hotplugx only turn the second core off if the CPU is in it's lowest allowed frequency.
[Samsung Galaxy Nexus] tnap1979:
ok, thanks alot :)

and ive been reading a few post above, whats with all these tweaks to governers, can i do this and get better performance from my device?

im just looking to make the best out of my old nexus.. its served me well, its been thru water damage and survived, its been dropped, thrown, banged, and stepped,

i feel i dont NEED a new device if i can squeeze every ounce of juice from it i can till i need to upgrade due to better stuff,

im not intent on the nexus 4, im actually quite annoyed with the "iphone like" glass back and internal battery...

so yea, any method like those above mentioned tweaks, and or best kernel/governer/rom adivce?

im currently using PA 3.10 mar 09, newest gapps, updated bootloader and baseband from stock google 4.2.2 image

so really only thing i need to get good is what kernel and gov. and any additional tweaks like V6 supercharger (if even needed)
[Samsung Galaxy Nexus] reysonance:
Best ROM/Kernel is highly subjective.

And I personally doesn't use supercharger since I'm pretty content with the stock lmk, launcher redraws is not something I frequently encounter.

The tweaks which can be found here is to further improve the performance of the kernel itself, it's also cross-compatible with other tuna kernels, so you won't miss out the fun if you change your kernel for instance.
[Samsung Galaxy Nexus] twistedumbrella:
[KERNEL][GPL][GN] franco.Kernel r366 -&gt; 4.2.2 | r364 -&gt; 4.2 | r300 -&gt; 4.1

If it freezes once, that only means you didn't hit the frequency long enough the other time. For a real test, you need to lock your CPU at the frequency you're focusing your voltage changes on.

Mind sharing your references? This sounds like assumptions and since it contradicts everything I've tested, I would like to see how these results were found to compare them fairly.
[Samsung Galaxy Nexus] reysonance:
I did set the min/max at 1228, it seems that it only happens with Trickster, although I can't replicate it. Other slots are also unaffected by the voltage change, it's like a weird one-time thing.

---------- Post added at 10:08 PM ---------- Previous post was at 10:02 PM ----------

I did a personal run for about a week with InteractiveX, and three days with hotplugx, with a CPU monitor, I didn't notice much difference with iX on idle drain, neither with hotplugx, the only thing I notice with hotplugx is the that it only hot plug on lower CPU frequency, and does nothing on higher slot, of course this test is uncontrolled and subjective.

You say that it contradicts your findings, mind sharing that? :) Would love to learn more than just testing one of few days in an uncontrolled environment.

EDIT: I'm trying out hotlugx one more time right now to see how it fares, I'll report my findings in a week if necessary. Although the last time I did this it helps a little when I spend a lot of time on apps that spend it majority of time in the lower frequency (reddit, talk etc.), although not drastic. Could be placebo though, since I doesn't have enough data to properly compare.
[Samsung Galaxy Nexus] malaroth:
Re: [KERNEL][GPL][GN] franco.Kernel r366 -&gt; 4.2.2 | r364 -&gt; 4.2 | r300 -&gt; 4.1

Question: is there gonna be a fix on fast charge for Gnex? Or is it just the toast notification that's missing? I use fast charge daily
[Samsung Galaxy Nexus] osm0sis:
Yeah I'd still be interested to have more benches and opinions on all 4 though. Independently verify. ;)
[Samsung Galaxy Nexus] twistedumbrella:
Re: [KERNEL][GPL][GN] franco.Kernel r366 -&gt; 4.2.2 | r364 -&gt; 4.2 | r300 -&gt; 4.1

My testing was done with daily charge cycles. A full cycle on one then a full cycle on another. I was noticing the longer days were hotplug governors. One thing to consider is if you are changing the governor for both cores or not. A lot of times the hotplug governor is set on the first core, but the second one remains default. That will kill any possibility of it making a difference.
[Samsung Galaxy Nexus] reysonance:
Just realized this, cpu1 is sticking on interactive, tried everything I could think of, also, affected_cpus only list cpu0, does than mean anything?

EDIT: Never mind, crisis averted.
[Samsung Galaxy Nexus] J-Hop2o6:
Good lookin'. Will test out today.
[Samsung Galaxy Nexus] pkgnex:
Osmosis & Malaroth,

Spent a lot of time this morning on CFQ tunables. My benchmarks and subjective evals show quantum = 8 is the sweet spot. I tried 2, 4, 6, 7, 8, 9, 10, & 12... and I previously knocked 32 & 64 out of the running.

The benchmarks for the idle parameters were best with both set to 0, with both set to 7 as a close second.

Now here's where I got a little creative and may have stumbled upon something new. Setting the back_seek_penalty to 1 instead of 2 definitely speeds everything up, regardless of the back_seek_max value. It also appears that the i/o benchmark is best with back_seek_max set between 100,000 & 20,000,000. Generally, even numbers are better, but I got really good results with 16,777,216 (16 Gb converted to kb... I have a 32 Gb device) as well.

My hypothesis after re-reading Os's links is that setting the penalty to 1 removes the penalty for backward seeking, which I think shouldn't need to be penalized with flash memory, and setting back_seek_max to around half the device's memory may limit the time searching backwards such that you're not searching full circle back to a place in memory that could be more quickly found by searching forward. Hope you understand that - makes sense in my head, but it's hard to put into words.

All that said, even setting back_seek_max to 0 wasn't too bad. I think the flash memory is just so fast that it doesn't matter as much as some of the other parameters.

If anyone else would like to try these settings in absence of updating the script, let me know what you think:

Quantum = 8 (already in script)

Back_seek_penalty = 1

Back_seek_max = 16777216 or half your device mem. in kb

Slice_idle = 0

Group_idle = 0

Edit: Looks like setting the penalty to 1 is already in the script, too. I must have been working from an old version. And I thought I came up with something new today! Oh well.
[Samsung Galaxy Nexus] --__LoRiS__--:
R: [KERNEL][GPL][GN] franco.Kernel r366 -&gt; 4.2.2 | r364 -&gt; 4.2 | r300 -&gt; 4.1

How can i set scheduler settings at boot? Init.d? If yes can you tell me how to do it? Thanks
[Samsung Galaxy Nexus] stevensoaj:
For the record, the newest version of trickster allows you to set IO scheduler settings at boot if you have purchased the donate key. :good:
[Samsung Galaxy Nexus] pkgnex:
Yep, init.d

Verify your rom/kernel supports init.d (most non-stock ones do)

Download the io script from Malaroth's signature.

Place the file in /etc/init.d with root browser or similar (create the init.d folder in /etc if needed)

Delete the .txt extension

Set folder and file permissions to rwx/r-x/r-x

Reboot

Profit
[Samsung Galaxy Nexus] Khrushy:
Re: [KERNEL][GPL][GN] franco.Kernel r366 -&gt; 4.2.2 | r364 -&gt; 4.2 |-&gt; 4.1

Fast charge seems fine to me. Mind you, I turn it on by default in init.d then toggle it with quick toggles to use the USB connection and I do this specifically to avoid the toast notifications. It's not working for you?

Also going to be testing cfq for a few days. So far it seems smooth, but not noticeably better or worse than row. Will update after more use and tooling around.
[Samsung Galaxy Nexus] peikojose:
Re: [KERNEL][GPL][GN] franco.Kernel r366 -&gt; 4.2.2 | r364 -&gt; 4.2 | r300 -&gt; 4.1

What do you think is the best governor and scheduler to increase battery life ? Thanks
[Samsung Galaxy Nexus] pkgnex:
Lazy governor should conserve the most battery, but it will have slow response. Not sure scheduler selection matters much.

You should try some different governor / scheduler combinations and see how they work for you... That's the beauty of Android.
[Samsung Galaxy Nexus] shreddintyres:
Re: [KERNEL][GPL][GN] franco.Kernel r366 -&gt; 4.2.2 | r364 -&gt; 4.2 | r300 -&gt; 4.1

Varies from person to person and device to device depending on your usage and you particular device. Beat way to find out is to treat each for your self

That said I like using interactive governor and the row scheduler. I find it to be very responsive and gives me decent to respectable battery life. A lot of people like inactive with deadline. But again try it out for your self and decide which works best for you.
[Samsung Galaxy Nexus] osm0sis:
Whew.. long day at work! Here goes..

Oh don't worry bro, I was just tweaking the easy ones first for solid state/high-perf/flash drives so we'd have a starting point for you to do sync and async expires, and further tweaking on top of that. That was the plan all along. ;) We'll be glad to have you back when you're ready.

franco.Kernel for tuna doesn't allow you to control the hotplugging anymore because there were a lot of reports of cores turning off and never coming back on. As far as I know Francisco has it at stock kernel hotplug code, which will still autohotplug when it meets the right conditions. If you like, I think if you do a search for franciscofranco posts with the keyword hotplug you'll get roughly that statement but from the horse's mouth. :)

I used fast charge the other day, I believe it works fine. Got the notification warning and everything. Correct me if I'm wrong, but I don't recall there being a toast since the rewrite of f.Ku.

Wow. Again, great work! Invaluable having someone else who knows what they're doing testing and benchmarking, so thank you very much for your efforts. :D back_seek_penalty 1 was there since we started adding test values to the iosettings script. That was the first tweak I made to make sure the calculation (1/x) was 1/1 disabling the penalty. Memory "wrapping around" is a very interesting idea for back_seek_max. Are you finding 16777216 superior to our previous favorite of 1000000000? I have a 16gb GN so I'll try 8388608 as well to see if we can prove your hypothesis or if a common value will be fine.

Originally my thinking with back_seek_max was that it would be better basically at infinity, basically disabling it like the penalty. So I'd hoped 0 might do that, or the absolute max accepted value of 2147483647 (2 TB, minus 1 KB), but oddly the even 1000000000 seemed better. If you're right about even numbers being better, perhaps due to my idea of the calculations being simpler, then 2147483646 would be worth a try in lieu of the actual 2 TB value of 2147483648. I'll mess with these too and see what I can tell. :good::cowboy:

You've been around long enough that you should know to read back a few pages to see that this was recently asked. You should also know how to search the thread by now.

I feel scheduler does matter right now, but hopefully not as much when we're done with them. :p The general queue tweaks we've made (some already present in r366) have definitely gone a long way towards improving them across the board though.
[Samsung Galaxy Nexus] pkgnex:
"

"Wow. Again, great work! Invaluable having someone else who knows what they're doing testing and benchmarking, so thank you very much for your efforts. :D back_seek_penalty 1 was there since we started adding test values to the iosettings script. That was the first tweak I made to make sure the calculation (1/x) was 1/1 disabling the penalty. Memory "wrapping around" is a very interesting idea for back_seek_max. Are you finding 16777216 superior to our previous favorite of 1000000000? I have a 16gb GN so I'll try 8388608 as well to see if we can prove your hypothesis or if a common value will be fine.

Originally my thinking with back_seek_max was that it would be better basically at infinity, basically disabling it like the penalty. So I'd hoped 0 might do that, or the absolute max accepted value of 2147483647 (2 TB, minus 1 KB), but oddly the even 1000000000 seemed better. If you're right about even numbers being better, perhaps due to my idea of the calculations being simpler, then 2147483646 would be worth a try in lieu of the actual 2 TB value of 2147483648. I'll mess with these too and see what I can tell. :good::cowboy:"

"

I'm pretty sure I mixed some Linux default values in with Malaroth's script early on (pulling too many levers at once), but at least we ended up at the same place. That's encouraging!

I'm probably over-thinking the 16777216 thing, but it did seem that numbers lower than 1Tb worked a little better for me. 100 Mb to 10 Gb were the sweet spot I found, and the half memory value lies just outside this range and also seemed good. 1XXXX numbers seemed better than 5XXXX numbers - don't know why. I'd honestly be OK with anything between 100 Mb and 1Tb if others find a different sweet spot.

I also did some work on iostats and nr_requests this evening:

iostats doesn't seem to matter that much, but I did have one lag / freeze with it set at 1 and I can buy your reduced overhead argument, so I vote for keeping it at 0.

I feel that nr_requests is better at 512 than 1024. My phone seems to be snappier at 512, and the benchmarks validate it is at least a little better (5%-10%). I tried 256, 128, and even 2048. All were terrible when pushing my phone hard (rapid app switches, etc) - laggy, choppy, freezes, and again the benchmarks were poor - especially for the more extreme values. There could be a "sweeter" spot between 512 and 1024, but it would have to be some uncommon value I suppose.

So, my current recommended values to try (and possibly for others to tweak more) would be as follows:

8 / 125 / 250 / 16777216 / 1 / 93 / 39 / 2 / 0 / 0 / 1

iostats = 0

nr_requests = 512

... and that's about all the CFQ tunable testing I have in me for now.
[Samsung Galaxy Nexus] osm0sis:
Great work again! :highfive::) In between 512 and 1024 would be 768, see how it compares to your tests with the other two. :D:cool:

Then get some rest, buddy. Don't get burnt out; like I said, this is still phase one. ;) Your work is highly appreciated, and your input has been highly valuable. Thank you for it all.
[Samsung Galaxy Nexus] pkgnex:
768 between 512 and 1024... funny guy!

Seriously, I tried it and 512 still beats it. Previous post recommendation still stands.
[Samsung Galaxy Nexus] Khrushy:
Thanks pkgnex, giving those settings a go now. Initial reaction is that it's just as snappy as row, but a touch more consistent. Will report back later.
[Samsung Galaxy Nexus] pkgnex:
Thanks, but it wasn't all me... Just took the ball and ran with it for a while.

I agree with your initial reaction. For the first time, I'm actually kind-of liking cfq (on a flash device).
[Samsung Galaxy Nexus] bigbear6708:
Re: [KERNEL][GPL][GN] franco.Kernel r366 -&gt; 4.2.2 | r364 -&gt; 4.2 | r300 -&gt; 4.1

Do I just apply the malaroth script as is...or should I cut out the tweaks for scheduker I'm not using out?
[Samsung Galaxy Nexus] pkgnex:
You can use it as-is, only active scheduler settings are applied. The cfq settings discussed today are almost certainly not in it, but you can change them as needed / if you want.
[Samsung Galaxy Nexus] galakanokis:
Re: [KERNEL][GPL][GN] franco.Kernel r366 -&gt; 4.2.2 | r364 -&gt; 4.2 | r300 -&gt; 4.1

I can't get the damn init.d script to work. There are a bunch in there and I think they are conflicting.

Can I rename them to any number from 1 to 99 to have them run in that order? Sorry guys, just not to familiar with init.d scripts. Permissions are correct I really believe it is some sort of conflict.
[Samsung Galaxy Nexus] nuchdog:
Re: [KERNEL][GPL][GN] franco.Kernel r366 -&gt; 4.2.2 | r364 -&gt; 4.2 | r300 -&gt; 4.1

Yep. Thats how it should work.
[Samsung Galaxy Nexus] Kurre:
You could try running the script via terminal or script manager app. That way you can be sure that the script itself is running correctly (and if not, paste errors here to be examined). After that it's only a matter of correct permissions etc in init.d folder.
[Samsung Galaxy Nexus] pkgnex:
^^^ This. Try the script manager app. Use the app to browse to your file and run the script. If the run completes, the problem is probably that your scripts are being over-written by the rom or kernel later in the boot cycle. You could then try adding some sleep statements in your first script like many others have had to tinker with, or just set up the script manager app to run your scripts after boot.
[Samsung Galaxy Nexus] bigknowz:
Loop?

Check out this comment on lean thread.
[Samsung Galaxy Nexus] osm0sis:
Interesting that would cause a problem. It suggests systemui never loads, which is impossible and crazy, because systemui = everything.

Anyway. I just spent a good bit of time benchmarking with AndroBench and it's very hard to see any real differences with group/slice idle or backseek max values. The results pretty much all fall inside the normal range of variability if you run repeat tests long enough. One thing that did make a consistent difference was nomerges 0 which drops the macros test times significantly. I'm thinking that merges should be reenabled despite how good on paper it sounds to make deadline, row and cfq a little more like noop/sio.

Now I'm running SD Card Tester because you can actually watch the writes choke with it. The choking is what decreases the speeds as it continues, and I'm already seeing results.
[Samsung Galaxy Nexus] pkgnex:
I agree on all counts.

Just tried nomerges at 0, and what a difference (on cfq)! The behavior difference with this change has me wondering if all the other values need to be rechecked with merges on...

I think it makes sense that if users want a non-merging fifo-type scheduler, they can use noop.
[Samsung Galaxy Nexus] J-Hop2o6:
Where are these so called iostats , nr_requests , and nomerges? No where in franco's app.
[Samsung Galaxy Nexus] szale9001:
Lol yea, that was me. I thought the same: not sure how that could be the issue but removing those lines definitely fixed it and leaving them in definitely left me at the Google logo until I pulled the battery. Not really sure why. Possibly a difference in how each kernel runs init scripts?
[Samsung Galaxy Nexus] Kurre:
those are in /sys/block/mmcblk0/queue and you need to echo wanted values.
[Samsung Galaxy Nexus] osm0sis:
My only guess is that it was actually waiting for the script to finish before continuing with the boot; not usually how init.d should work. If it's implemented correctly it should just be a call to busybox run-parts that happens in the background while the rest of the OS continues to load.
[Samsung Galaxy Nexus] bigknowz:
Check init.d settings

I wrote this script to make sure the init.d tweaks for deadline took hold without going into terminal and typing each line. It puts all the expected values and actual values into a file and then shows the contents of the file (checkdl.txt). You may need to edit some values, I change minfree and use 1024 read ahead. You can also add the cfq and row values if you like. I guess a better programmer could take the values from the 95io0settings file as opposed to manually entering. Hope it helps.
[Samsung Galaxy Nexus] .:Crack:.:
RD Pikachu01 (script thread) suggests these row values, what's your opinion? He also has cfq & deadline tweaks in that script.

echo "20" > $i/queue/iosched/hp_read_quantum;

echo "20" > $i/queue/iosched/rp_read_quantum;

echo "5" > $i/queue/iosched/hp_swrite_quantum;

echo "4" > $i/queue/iosched/rp_write_quantum;

echo "4" > $i/queue/iosched/rp_swrite_quantum;

echo "2" > $i/queue/iosched/lp_read_quantum;

echo "2" > $i/queue/iosched/lp_swrite_quantum;

echo "5" > $i/queue/iosched/read_idle;

echo "15" > $i/queue/iosched/read_idle_freq;

I told him lp_swrite_quantum is calculated a bit stangely and he just told me it's a bug. I suggest his echoed value is the one he wants to receive for cat /[...]/lp_swrite_quantum.
[Samsung Galaxy Nexus] lippol94:
I know Pikachu since the I9000 development times and he really knows what he does.

Thing is that his script was written for and exclusevely for I9000 Galaxy S and later adapted to work on any (?) phone.

I guess you can try those values, but YMMV as you're trying them on a different hardware,
[Samsung Galaxy Nexus] osm0sis:
init.d scripts are shell scripts. You can just run 950iosettings as is provided you've got the permissions correct.

Pikachu is an expert tweaker. I checked out some of his scripts before starting work on cfq to see what other people were doing. He's very clever, much respect, but he's wrong about it being a bug since we could figure out the equation for it. It's just the way it is, like different devices having different scales for accepted values.

His values make row not really favor reads at all anymore by comparison so it'll lose a fair amount of its snap compared to ours. Note the others ended up about the same which is cool independent support. I'll go with the read idle values malaroth worked out though; due to the different scales on different devices read idle 5 wouldn't be possible anyway.
[Samsung Galaxy Nexus] Khrushy:
Re: [KERNEL][GPL][GN] franco.Kernel r366 -&gt; 4.2.2 | r364 -&gt; 4.2 | r300 -&gt; 4.1

+1 on the no_merges = 0 thing. Definite improvement with cfq.

Which actually makes sense if you think about it. The main complaints were during large file operations - while no_merges 1 should improve total throughput by lowering overheads, it's not going to prioritise the user experience by merging UI commands etc into the queue while it's handling other large operations.

Basically saying "**** you user, I don't care if you want to interrupt my current file write to scroll your home screen, wait till I'm done, then I'll scroll for you".

Total throughput might be up, but usability is definitely down.

Or did I completely misinterpret the way it works?
[Samsung Galaxy Nexus] osm0sis:
Yeah that's about right. :p

Throughout doesn't even seem really improved by limiting it to only simple merges. I think it was just a theory Franco had that making them more like sio/noop would improve it by decreasing overhead but that doesn't seem to be the case either way.

Only way we could use benchmarks to tell the differences between most of the cfq values we're interested in for phase one here would require a hundred or thousand tests to find averages since the variability is so big. SD Card Tester was less reliable with repeat tests too, sometimes choking sometimes not. If that's what we need to figure it out then our margins for improvement are also pretty narrow here.

I agree. The deadline tunables at least might need some tweaks now that merges are enabled again. Specifically raising fifo_batch to something that feels good and maybe also enabling front merges again.
[Samsung Galaxy Nexus] JBNex:
Re: [KERNEL][GPL][GN] franco.Kernel r366 -&gt; 4.2.2 | r364 -&gt; 4.2 | r300 -&gt; 4.1

So if I run the ioscheduler manually in Terminal, I'd expect dozens of errors about cannot find file for the other schedulers but in the end the settings were applied successfully?
[Samsung Galaxy Nexus] bigknowz:
Not following

I don't understand your question. That lean poster said he took out the wait for com.android.systemui

# wait for android os

until [ `pidof com.android.systemui` != "" ]; do

sleep 1

done;

and his init.d settings took.
[Samsung Galaxy Nexus] osm0sis:
That's correct. It tries to apply them all but of course only the ones for the active scheduler work.