row Tunables

[malaroth]

http://db.tt/6OZyQCcX

Here's the values although on the n7 read_idle is 20 not 15. Download is init.d script to easily implement

#!/system/bin/sh
#chmod -R 755 /system/etc/init.d

echo "row" > /sys/block/mmcblk0/queue/scheduler
echo 100 > /sys/block/mmcblk0/queue/iosched/hp_read_quantum
echo 75 > /sys/block/mmcblk0/queue/iosched/rp_read_quantum
echo 5 > /sys/block/mmcblk0/queue/iosched/hp_swrite_quantum
echo 4 > /sys/block/mmcblk0/queue/iosched/rp_swrite_quantum
echo 3 > /sys/block/mmcblk0/queue/iosched/rp_read_quantum
echo 1 > /sys/block/mmcblk0/queue/iosched/lp_read_quantum
echo 1 > /sys/block/mmcblk0/queue/iosched/lp_swrite_quantum
echo 15 > /sys/block/mmcblk0/queue/iosched/read_idle
echo 25 > /sys/block/mmcblk0/queue/iosched/read_idle_freq

[Joaquín]

row users rejoice! Let's the testing begin.

I've flashed the stock google image on both of my nexii so i have a clean base for testing.

malaroth the link you've posted unfortunately isn't working so i've uploaded both grouper and maguro scripts and here are the downloads links:

grouper: http://d-h.st/zAf

maguro: http://d-h.st/B26

And here is another one to set the read ahead buffer size (RABS) to 512 http://d-h.st/TRE

[malaroth]

http://db.tt/9F0maV4a I've redone the files and uploaded them again to dropbox. This is corrected one

[Zach (malaroth)]

One thing still holding this one back for me is not knowing where people are having lags and hangups. If you see any comments on it or see it yourself I could probably figure which value to tweak. Have I taken too much read priority away or not given enough write boost is what I'm looking for.

[Steve (Gingerbread Man)]

These values are excellent Zach iv just been trying them. I'd say move on to bfq / cfq but with these and the grouper test.IMG I can't make my tablet lag

[Joaquín (joaquinf)]

Hi guys!

Today on the maguro thread was reported a typo in these row tuneables, and indeed there is one lol. Check these two lines

echo 75 > /sys/block/mmcblk0/queue/iosched/rp_read_quantum

echo 3 > /sys/block/mmcblk0/queue/iosched/rp_read_quantum

Both are setting the same variable to a different value, therefore messing up the tuneables set on boot. The correct thing should be:

echo 75 > /sys/block/mmcblk0/queue/iosched/rp_read_quantum

echo 3 > /sys/block/mmcblk0/queue/iosched/rp_write_quantum

and the whole thing is:

#!/system/bin/sh

# chmod -R 755 /system/etc/init.d

sleep 35;

echo "row" > /sys/block/mmcblk0/queue/scheduler;

echo 100 > /sys/block/mmcblk0/queue/iosched/hp_read_quantum;

echo 75 > /sys/block/mmcblk0/queue/iosched/rp_read_quantum;

echo 5 > /sys/block/mmcblk0/queue/iosched/hp_swrite_quantum;

echo 4 > /sys/block/mmcblk0/queue/iosched/rp_swrite_quantum;

echo 3 > /sys/block/mmcblk0/queue/iosched/rp_write_quantum;

echo 1 > /sys/block/mmcblk0/queue/iosched/lp_read_quantum;

echo 1 > /sys/block/mmcblk0/queue/iosched/lp_swrite_quantum;

echo 20 > /sys/block/mmcblk0/queue/iosched/read_idle;

echo 25 > /sys/block/mmcblk0/queue/iosched/read_idle_freq;

Just want to make sure we are testing the same tuneables ;) 

Not much to report other than a smooth experience. The only lag i could perceive is sometimes when exiting from an app by pressing the home button it took like one second to perform the next action (e.g open the app drawer) but after two seconds everything is back to normal.

[Zach (malaroth)]

Thanks for catching that. I was sick when I wrote it out and it should be

#!/system/bin/sh
#chmod -R 755 /system/etc/init.d

echo "row" > /sys/block/mmcblk0/queue/scheduler

echo 100 > /sys/block/mmcblk0/queue/iosched/hp_read_quantum
echo 75 > /sys/block/mmcblk0/queue/iosched/rp_read_quantum
echo 5 > /sys/block/mmcblk0/queue/iosched/hp_swrite_quantum
echo 4 > /sys/block/mmcblk0/queue/iosched/rp_swrite_quantum
echo 3 > /sys/block/mmcblk0/queue/iosched/rp_write_quantum
echo 1 > /sys/block/mmcblk0/queue/iosched/lp_read_quantum
echo 1 > /sys/block/mmcblk0/queue/iosched/lp_swrite_quantum

echo 15 > /sys/block/mmcblk0/queue/iosched/read_idle
echo 25 > /sys/block/mmcblk0/queue/iosched/read_idle_freq

I typed rp_read_quantum when it should have been rp_write_quantum

[Joaquín (joaquinf)]

It was a guy in maguro's thread that found the typo. The tuneables i posted are for grouper and yours are for maguro , so technically both are correct :p

read_idle for maguro = 15

read_idle for grouper = 20

[Zach (malaroth)]

Yeah but I also screwed up and double posted rp_read_quantum. This last should work. And yes I thought I explained that Gnex is increments of 8 after the original 7ms while grouper is increments of 10ms

[Zach (malaroth)]

Honestly before Franco implemented the scheduler changes I had zero experience with programming. I taught myself in a month what I do know so bear with me ;-)

[franciscofranco1990]

And that is awesome :)

Can you give me an updated list of those tunables? I got confused with the typos and what most. Shame you guys don't have a Mako :(

[Zach (malaroth)]

Row-tuna http://db.tt/eu6sWQea and row-grouper http://db.tt/gZ8ZAgbk

[Steve (Gingerbread Man)]

Thanks Zach for these am running both now and am yet to find any lags my n7 feels particularly amazing. The read ahead value set to 512 seems to make a bigger difference to my n7 than my gnex. Both devices are running at their best performance judging by feel (am yet to run any benchmark).

[Zach (malaroth)]

https://play.google.com/store/apps/details?id=com.cgollner.benchmark

Awesome benchmark app Franco and his best friend developed

[Chris (osm0sis)]

Seems we don't need two separate scripts for row either. grouper will automatically turn the 15 into a 20. :)

 

P.S. row kicks the shit out of deadline on the GN with your tweaks Zach! deadline still seems to win on the N7 for me though... Weird!

[Chris (osm0sis)]

Still getting some freeze/choking with Play Store downloads, so I think we should favor writes some more.

[Zach (malaroth)]

[QUOTE=shreddintyres][QUOTE=malaroth][QUOTE=shreddintyres]Hey bro,

sorry for the long delay in my response regarding the tunables you provided (school has been keeping me insanely busy) so far i have found them to work pretty well, dont notice any major hiccups. installs from teh market seem to take less time however (not sure if this is due to me running through a proxy and higher load on their end) i have noticed that downloads from the market seems to be taking longer than normal.

Exporting files (roms) from dropbox to sd card feels like its about the same but definitely slower than when i use deadline.

I generally dont do much writing to my device so use in applications like chrome etc feel about the same if not a tad faster, tho it is hard to really tell thanks to interactive and 365 being so ridiculously fast.

i know this is likely less than helpful, please let me know if there are any specific tests you would like me to perform to give better feedback.

- Cheers[/QUOTE]
No man that'll work. Your app downloads are gonna be regular swrite or even hp swrite. Same with pulling roms from dropbox. I'll look at bumping the numbers and see. In your script instead of 5 4 3, try 6 4 4 or even 6 5 4 for hp_swrite rp_swrite and rp_write. Let me know if that makes a difference

Franco r365
JBSourcery 4.5.5[/QUOTE]

After testing each for about a day, im finding that 6 5 4 seems to feel a bit better overall, feels much snappier, im betting it has something to do with the higher hp_swrite_quantum value. so far it hasnt seemed to affect the battery life at all. I'm going to continue testing 6 5 4 for a bit longer to be sure it isnt a placebo affect[/QUOTE]

[Chris (osm0sis)]

K. trying them out. What about also bumping lp write to 2 for good measure?

[Zach (malaroth)]

[QUOTE=shreddintyres]seems to be working well, no freezes to really report, there is a momentary lag when installing an application from the market after it has downloaded, but beyond that seems to work really well, only thing i can think of to improve that any more is to increase the write quantities but that kinda would kill any true benefit you get from ROW and should rather run deadline.

so 100/75/6/5/4/1/1/15/25 seems to be working well[/QUOTE]

And I asked him to bump lp_write to 2. We'll give it a couple days testing and then maybe we've got winning defaults

[Chris (osm0sis)]

Lp write is actually really weird. Doesn't seem to take values normally.

2=1
10=2
100=13

Frigging bizarre, so I'm going to leave it alone. Trying the others at 12 11 10 though.

[Steve (Gingerbread Man)]

Testing the set two posts ago by Zach feels a little faster than before.

[Zach (malaroth)]

Wondering if we can slip the noobs a ruffie and slide the row numbers in on them and see if the stuttering complaints get better or worse. All the feedback I've been getting from y'all and shreddin is that the 654 combo is the best I've been able to come up with. App installs from playstore are the common denominator in 90% of complaints

[Chris (osm0sis)]

Still getting some serious hangs during the install/updating part with 6-5-4. 12-11-10 was too sluggish overall.

[Zach (malaroth)]

Well damn. I go back and fiddle some more

[Steve (Gingerbread Man)]

I think that sounds like a good idea. Set row to default with 6 5 4 and see if anyone notices and give no change log and ask for feed back. About these play store freeze ups though, is there any chance its an app issue with the play store rather than somehow being the kernels fault? I don't have any evidence to support it but I've never had any issue with the play store or updating applications.

[Zach (malaroth)]

I had to put those numbers out in the xda forums. If it'll stop the freaking whining about lag. For real I don't think 99% of them have read the post about the development forum being about the journey, not the destination. I also think that's why you're so quiet lately Franco, besides being busy. Who wants to Wade through a forum of uninformed rants?

[Steve (Gingerbread Man)]

Zach you might want to update your xda signature links to those scripts to include the 6 5 4 changes. Thanks for having them in place so now I have the correct values set read idle and read idle freq which I didn't notice were different originally.

[asqureshi2007]

hey yall this is my first post here, but this is what ive come to for row after having several discussions with malaroth, Market lag is nearly gone with this but there is still a momentary pause but no more debilitating device freezes during install/uninstall

echo 100 > /sys/block/mmcblk0/queue/iosched/hp_read_quantum;

echo 75 > /sys/block/mmcblk0/queue/iosched/rp_read_quantum;

echo 6 > /sys/block/mmcblk0/queue/iosched/hp_swrite_quantum;

echo 5 > /sys/block/mmcblk0/queue/iosched/rp_swrite_quantum;

echo 4 > /sys/block/mmcblk0/queue/iosched/rp_write_quantum;

echo 2 > /sys/block/mmcblk0/queue/iosched/lp_read_quantum;

echo 10 > /sys/block/mmcblk0/queue/iosched/lp_swrite_quantum;

echo 15 > /sys/block/mmcblk0/queue/iosched/read_idle;

echo 25 > /sys/block/mmcblk0/queue/iosched/read_idle_freq;

[Chris (osm0sis)]

Echoing 10 to lp write gives you a returned value of 2. Are we okay with how weird this is?

P.S. Welcome aboard 'tyres!

[shreddintyres]

until malaroth pointed out to me that echo'ing 2 didnt work and i had to echo 10. I Agree its extremely strange , funny part is that you run "cat /sys/block/mmcblk0/queue/iosched/lp_swrite_quantum" will return 2 despite having echo'd 10.

also if you go into f.ku and check the setting it will also read 2 when you click on lp_swrite but displays 10 outside the edit field. 

thanks osmosis, hopefully i can actually contribute something of worth

[Zach (malaroth)]

Any of you know of the buddy algorithm? I read a brief bit of a very technical paper and I think it may just correspond to why some values set to any sequential number, while others jump and change incrementally. Has to do with breaking the data down /2 till it's in a preset "manageable" size. Where lp_write is the actual number of writes, it would seem that synchronous writes have to be managed with the buddy algorithm to not create too large a process. Finding the increment size tells it that x = maximum size for synchronous writes (or reads) so the value y must be y=< x or else y must be halved until it is. Make any sense? My math sucks and my Linux knowledge is non existent but it seems to fit the issue

[franciscofranco1990]

Argh! Lots of info around. I don't know much about ROW so I can't help much. Besides of thatI guess you guys have some questions about how those values are being set in the source etc, I need a list of every variable that you need help understanding then I'll go through the list and read the source code and post here. Thank you, a list will save me a lot of time that I don't have :)

[shreddintyres]

I think the only value we are really having difficulty (atleast my self) understanding is why and how lp_swrite_quantum is handled, has very peculiar behavior as Osmosis pointed out earlier  

echo 1 = 1 

echo 10 = 2

echo 13 = 3 

near as i can tell no easily discernible pattern to how its handled within f.ku or by the kernel it self

[franciscofranco1990]

What happens if you set 110? I really cant test at the moment, building something for Mako.

[shreddintyres]

setting to 110 in f.KU and via terminal returns a value of 15 when i run cat /sys.../lp_swrite_quantum

[Chris (osm0sis)]

So 100 = 13, 110 = 15. So weird.

 

It's also completely different on the N7 to the GN. 10 still gives 1 on the N7, doesn't switch to 2 until 11 or 12.

[Zach (malaroth)]

I think lp_swrite_quantum and read_idle are the only ones we're troubled by. Is there an equation like I mentioned with the buddy algorithm a few posts back that make values incremental instead of sequential? And I've got a LOT to learn still Mr Franco Sir. No big ego here. A lil daunted by the notice I've gotten for grinding out the deadline values. But yeah it seems to work setting row to 100/75/6/5/4/2/10/15/25 on tuna that gets the best results. The 10 setting on lp_swrite_quantum returns a set value of 2 and is the smoothest yet, thanks to shreddin and Steve and Chris for chipping away at them.

[franciscofranco1990]

Echo 111 please.

[franciscofranco1990]

Echo 130 please as well.

[Zach (malaroth)]

111 = 15 while 130 = 17

[franciscofranco1990]

Try this: echo 0x15 > path

[shreddintyres]

echo 110 leads to 15,  echo 111 gives 15, echo 130 gives 17 

dafuq?

[Chris (osm0sis)]

Okay, so going by the first values where they change: 

 

GN: 110 = 15, 118 = 16, 126 = 17.

 

Looks like some kind of fucked up 8 scale to me.

 

Edit: Yup. y=(x/8)+1 ;)

 

0=1

8=2

16=3

etc...

 

Edit 2: No not quite right.. since 126=17... hmm.

[Chris (osm0sis)]

0x15 =  1073741822

[franciscofranco1990]

There is no 126. Its 0, 8, 16, 24, 32, 40, 48, 56, 64, 72, 80, 88, 96, 104, 112, 120, 128...

[franciscofranco1990]

ROW driver is not the same on all Nexuses because of the kernel version differences. I can try and sync them all in the same ROW version, but I doubt thats gonna be possible.

[Chris (osm0sis)]

126 is the first value where it does becomes 17. 8s do seem to work though.

 

I'm about to output all the values up to 1000 via a loop, so we'll see what' up. ;)

 

Edit: 

#!/system/bin/sh

 

target=/sys/block/mmcblk0/queue/iosched/lp_swrite_quantum
i=0
until [ $i == '1000' ]; do
  echo $i > $target
  cat $target >> /sdcard/output.txt
  i=$(( $i + 1 ))
done

 

 

[Chris (osm0sis)]

Let's get weird:

 

0 = 1
8 = 2
16 = 3
24 = 4
32 = 5
40 = 6
47 = 7
55 = 8
63 = 9
71 = 10
79 = 11
87 = 12
94 = 13
102 = 14
110 = 15
118 = 16
126 = 17
133 = 18
141 = 19
149 = 20
157 = 21
165 = 22
172 = 23
180 = 24
188 = 25
196 = 26
204 = 27
211 = 28
219 = 29
227 = 30
235 = 31
243 = 32

 

So basically, for the GN it jumps by 8, but every so often it jumps by 7 instead. My quadratics are a bit rusty so I won't even try. :P

[Chris (osm0sis)]

N7 is actually pretty straight forward:

 

(0 = 1)

1 = 1
11 = 2
21 = 3
31 = 4
41 = 5
51 = 6
61 = 7
71 = 8
81 = 9
91 = 10
101 = 11
111 = 12

 

So we're looking at y=(x+9)/10 and it doesn't deviate from that (at least) all the way up to 1000 (ie. 991 = 100).

[Zach (malaroth)]

Awesome work Chris! You work those out like you were doodling bored in class :-P thanks man

[Chris (osm0sis)]

So if we want to set lp write 2 on both devices, I'm going to recommend a value of 12 for the universal script. Not sure if that'll jive with the N4 or N10 though, seeing as so far we're 2-for-2 on different devices having completely different scales.

 

lp write 2 seems to make the GN take a performance hit, but setting lp read to 3 seems to fix that. lp read 3 also seems to drastically improve the feel of paging through the app drawer. :D

 

Also I think the N7 performs better at read_idle 10 than read_idle 20, so for the universal script we should set 10. The GN will still turn that into a 15. :)

 

So everyone please give these a spin:

echo 100 > /sys/block/mmcblk0/queue/iosched/hp_read_quantum;
echo 75 > /sys/block/mmcblk0/queue/iosched/rp_read_quantum;
echo 6 > /sys/block/mmcblk0/queue/iosched/hp_swrite_quantum;
echo 5 > /sys/block/mmcblk0/queue/iosched/rp_swrite_quantum;
echo 4 > /sys/block/mmcblk0/queue/iosched/rp_write_quantum;

echo 3 > /sys/block/mmcblk0/queue/iosched/lp_read_quantum;
echo 12 > /sys/block/mmcblk0/queue/iosched/lp_swrite_quantum;
echo 10 > /sys/block/mmcblk0/queue/iosched/read_idle;
echo 25 > /sys/block/mmcblk0/queue/iosched/read_idle_freq;

 

Honestly though, I think the tweaked deadline values still wildly outperform row on the N7, hands down. And I feel the exact opposite on the GN.

 

Edit: New script version later in thread.

[Zach (malaroth)]

Lmao you're killing me here! great work on that. I'll run those through but you're usually right, except when you're wrong. It was quiet here for awhile and now a whirlwind. That's development I guess ;-)

[Chris (osm0sis)]

Haha I was bored in class. ;)

[shreddintyres]

Wow you get in bored in class and you figure out schedulers, i get bored in class and end up either falling asleep or stumbling.

6/5/4/3/2 seems to be working really well, smoother for me than 6/5/4/2/2 when using market, otherwise they feel the same. 

[Zach (malaroth)]

Lmao most of mine is at work... I figured out the deadline and row terms sitting waiting for customers. I was walking home when Franco first messaged me back asking if I even understood what the row values meant so I broke it down as best I could for him. I should find that pm. I need to go back and find that paper (again while I'm here at work) that explains the buddy algorithm cuz I really think that finding the equation that defines the term would benefit us

[Zach (malaroth)]

OK bored padawan.... tell me that this doesn't sound like what we're dealing with.... not you Aleem, this will DEFINITELY put you to sleep.
https://www.kernel.org/doc/gorman/html/understand/understand009.html

[shreddintyres]

lol thanks for the warning, immunology already has me there

[Zach (malaroth)]

I do and I don't understand it. It's above my head but I've been "training" my mind to think in unconventional ways since I learned to read at 3. Nothing's impossible, just rotate it and you've got a completely new landscape. Science fiction DOES pay off

[Chris (osm0sis)]

Hmm that stuff is a bit beyond me too, but it seems to be about memory allocation/management not i/o buffering so I'm not so sure it applies.

[Chris (osm0sis)]

Hmm anybody else's device never entering deep sleep? Mine's been awake for 13h now.. :/

Edit: Reboot fixed it. Probably just something still running in the background from when I was running those value test scripts.

[Zach (malaroth)]

Mine is... just checked with trickster... but I'm not using the latest 950 I don't think. Deadline is my daily driver and I haven't taken the time to boot to recovery and chmod the file yet. I just enter the tunable in Franco to test. For some reason terminal emulator doesn't like my phone and it's frustrating to push files when it keeps resizing. The window on me. Lemme do that now and I'll run it the rest of my shift which is 4 more hours and I'll let ya know

[Zach (malaroth)]

OK... so I'm an idiot and never set root rights in esfile explorer. Lemme mod that and I'll let you know

[Zach (malaroth)]

Eww just realized part of sourcerys init.d scripts is imo's mods :-P nah no offense meant. Competing kernels but nothing against the guy. I'm gonna create a dropbox zip of all the init.d scripts that are part of this rom Chris. Would you take a look and see if any of this is why I'm never seeing some of the problems that others do? Eagle with sourcery is a perfectionist and I've been running JBSourcery since a week after I got this Gnex

[Chris (osm0sis)]

Yeah sounds like fun, fire away. ;)

Send me your sysctl.conf too while you're at it.

[Chris (osm0sis)]

Francisco can you tell us if the scales are different again on the N4 and 10 for read_idle and lp_swrite?

[Chris (osm0sis)]

Test between 6/5/4/3/12 and 5/4/4/3/12 please. The latter is the fastest my GN has ever felt. :D

It also seems to improve row on the N7 slightly, though still not to the point that I'd choose it over deadline on it.

[Zach (malaroth)]

Figure out your deep sleep issue Chris?

[shreddintyres]

for me 5 4 4 3 2 12 seems to reintroduce lag that i had with market installs, freezes etc, granted they are no where near as debilitating as they were previously but more noticeable than 6 5 4 3 2 12 

[Zach (malaroth)]

That's about what I'm getting here... but I was gonna give it another 8 hours

[Zach (malaroth)]

Scratch that last. Restarting test. Tunable wasn't set properly. 7 hours of. Work left

[Zach (malaroth)]

In case you didn't catch this in the thread... preserved for posterity...QUOTE=.:Crack:.;38643482]Just did some very quick tests on how lp_swrite_quantum (probably some other tunables, too?) behaves when echoing a value.
For X € N [1;12] it seems like echo X > [...] results in cat [..] = X/3
i.e. if you echo 3, it will be 1, if you echo 9, it will be 3 and so on. for bigger values I did not really figure out how the applied value is calculated, i.e. if you echo 36 (to get 12) you*ll end up having 10; 40 will result in 11.

So does anybody know how and why these values are calculated as they are?

PS: Please note that I'm using an SGS I9000; the scheduler should be the same version/patch.

[Chris (osm0sis)]

Yeah I think it might be a little worse for the market, but that never really went away even at 6543, and for me I feel 5443 really improves the feel overall.

[Zach (malaroth)]

Market is a once in awhile thing for me so I'm going for overall feel. I'm kinda leaning towards you Chris. I'd not spaced the numbers right so the script never implemented. But... deadline. My phone just can't get more nimble than with deadline

[Steve (Gingerbread Man)]

I just editted my init.d for the 5 4 4 changes chris asked us to test, pretty much straight away I noticed a more snappy feel to my n7. Will be keeping will these values for the time being I think. Everyone should try these as it feels great

[Steve (Gingerbread Man)]

My n7 feels more like an iPad mini haha

[Joaquín (joaquinf)]

Wow guys you've really tuned the sh*t out of row. Reading through this topic was so much fun. I'm also testing 5/4/4/3/12 as chris suggested and it seems to be almost on pair with deadline on my n7. 

Well done guys

[Joaquín (joaquinf)]

Oh and i'm gonna try the benchmark & tunning app you recommended for testing.

Initial impressions: These row values seems to improve some micro lag i was having with swiftkey on deadline (grouper)

[shreddintyres]

i rescind my previous statement, 544 is definitely feeling better after giving it more time and looking at more than just the market. my apologies Chris.

market still has the momentary pauses when installing, but like everyone has said likely attributable to poor coding on google's part.

[Zach (malaroth)]

Just for curiosities sake is anyone running anything besides default window and transition effects at 1x? Where I'm seeing the most noticeable lag is in large surface flings i.e. top of Franco's xda thread to the bottom, and opening and closing new windows. Changing to .5x on new row numbers is what the deadline feels like at 1x

[Steve (Gingerbread Man)]

Iv kept the transition speeds all at stock 1x speed as normal daily settings, I tried changing to 0.5x and it does indeed feel quicker but I prefer it at stock 1x speed as it feels some what rushed. Now you come to mention it there is some minor lag / skipping effect if you fling from top to bottom on xda / Tapatalk threads but if you repeat it that won't happen again. I guess there needs to be boost to one of the write process but which one I don't know. Generally just using the device going through opening apps and scrolling feels faster. I'm happy to keep on trying values when time permits as I personally prefer row

[Zach (malaroth)]

LOL you're the reason I chose row to work on after deadline in the first place. The effects do "seem" to fade if you keep doing it but show back up later. If all I need to do is change to .5x I'm OK with that. I should probably try the old numbers at .5x too but hell... Chris Whatcha say to.throwing this in my sig and seeing what people say? Probably have to ask raikon to keep mum on it LOL. Always seems to check my sig first

[Steve (Gingerbread Man)]

Thanks I guess I didn't know that, thanks man! I think the values could be worked out a bit better as I'm not sure it would look entirely great on the xda threads saying this works great but set this, this and this to 0.5 speed, we need really fine tune these values and maybe the next set could be a more open test when you update your drop box files on your scripts. We are definatly making progress each time (when I see we I mean you too I'm the bitch tester hahaha) its quite funny as I'm probably the oldest here but by no means as intelligent and can't work out these mad maths equations you can when bored in class lol

[Zach (malaroth)]

No equations for me. Pure, dumb, steady turtle luck for me. Got the fiancées birthday party tonight but I'll be running 5/4/4 for the next day or so at .5x. If the only thing I'm experiencing is animation and transition effects that's easily solved though I wouldn't tops that out in the forum so quickly. I'm also thinking of going back to shiny rom since that's the most stock 4.2.2 Rom I know of that plays nice with my Gnex

[Steve (Gingerbread Man)]

Well have a nice time! Do you mind if I can ask for the source of where you read up on the ROW stuff you have learnt from and given time hopefully I might actually be able to come up with a set to try myself or help fine tune what we have on the go, it would be good to understand a little better what I'm doing

[Zach (malaroth)]

Actually I tackle row from the perspective that TOO MUCH read was priority over write and how could I introduce write without detracting from read priority. No source on this one

[Zach (malaroth)]

Other than the I/O scheduler guide in my sig that is

[Chris (osm0sis)]

Haha well the equation was just for shits. Didn't really use it for anything, just needed to figure out the first couple values for each device and where they overlapped so we could use a common setting.

As for the Dev options, I've always been 0.5x across the board. It's like increasing the mouse pointer speed in Windows, it might not be much faster but it *feels* a lot faster. And I've found the transitions since JB progressively gooier and slower/more annoying with each new release.. I'll try them at 1x to see what you guys are saying though. ;)

P.S. Never any need to apologize Aleem, we're all testing things out, not every device is made the same, mileage may vary and we're all entitled to our own opinions. :)

[Zach (malaroth)]

Changing back to 1x till tomorrow morning. Been running 5/4/4 with transitions and window animations at .5x and almost all St..stu...stutters are gone. Smooth and efficient, I haven't felt the urge to open cache cleaner or task killer to free up memory even once.

[Zach (malaroth)]

If that's a hint that you'd like to implement some changes overall and to get my butt in gear LOL I'd say go with

#!/system/bin/sh
# chmod -R 755 /system/etc/init.d

echo 512 > /sys/block/mmcblk0/queue/read_ahead_kb;
echo 2 > /sys/block/mmcblk0/queue/nomerges;
echo 2 > /sys/block/mmcblk0/queue/rq_affinity;

# wait for android os
until [ `pidof com.android.systemui` != "" ]; do
sleep 1
done;
sleep 20;

# deadline tweaks
echo 350 > /sys/block/mmcblk0/queue/iosched/read_expire;
echo 3500 > /sys/block/mmcblk0/queue/iosched/write_expire;
echo 6 > /sys/block/mmcblk0/queue/iosched/writes_starved;
echo 0 > /sys/block/mmcblk0/queue/iosched/front_merges;
echo 0 > /sys/block/mmcblk0/queue/iosched/fifo_batch;

# row tweaks
echo 100 > /sys/block/mmcblk0/queue/iosched/hp_read_quantum;
echo 75 > /sys/block/mmcblk0/queue/iosched/rp_read_quantum;
echo 5 > /sys/block/mmcblk0/queue/iosched/hp_swrite_quantum;
echo 4 > /sys/block/mmcblk0/queue/iosched/rp_swrite_quantum;
echo 4 > /sys/block/mmcblk0/queue/iosched/rp_write_quantum;
echo 3 > /sys/block/mmcblk0/queue/iosched/lp_read_quantum;
echo 12 > /sys/block/mmcblk0/queue/iosched/lp_swrite_quantum;
echo 15 > /sys/block/mmcblk0/queue/iosched/read_idle;
echo 25 > /sys/block/mmcblk0/queue/iosched/read_idle_freq;

That's the setup I'm running (did not change back to window ani 1x)
How bout you Chris? Steve? Aleem?

[Steve (Gingerbread Man)]

The script I'm using is almost the same except

# wait for android os
until [ `pidof com.android.systemui` != "" ]; do
sleep 1
done;

sleep 25;

Sleep 25 being the difference over your 20. I grabbed this one of chris I beleive it was originally but just editted the values as we have tested them. All animation, transition and windows speed still set to 1x

[Chris (osm0sis)]

Eh? Who was saying you need to get your butt in gear? Anyway, that's the old script again Zach. Steve's got it right. Sleep 25 was needed because grouper takes longer to boot, and also read_idle is 10. That still results in an outcome value of 15 for the GN. Bam. Universal. :D

[Steve (Gingerbread Man)]

Its only right cos its copied from chris I couldn't create a working script if I wanted I have been using the ones you guys been posting and editing them ;) As for boot time my n7 beats my gnex every time if I reboot simultaneously but allowing any extra time from sleep 20 - 25 should allow for differences within individual devices (not all are equal or the same) as we all know

[Chris (osm0sis)]

K, so here's the updated universal script, with the current finalized values for deadline and row, just so we're all on the same page. Should work for both GN and N7 (maybe others, need confirmation from Francisco about the deadline read_expire, and row lp_swrite and read_idle scales on the N4 and N10 to see), regardless of ROM, tweaking app, or boot length (other startup scripts, dalvik-cache wiped, etc.). All that's required is setting the scheduler of choice in the tweaking app then rebooting so the init.d can set the tunables to it.

 

I also included the JDQ39 cfq default tunables so we're all set for when we start playing with those. ;)

 

Edit: Latest script attached in cfq thread.

[Chris (osm0sis)]

We still need this too (re: rq_affinity):

 

On Saturday, February 16, 2013 9:07:05 PM UTC-4, franciscofranco1990 wrote:

Its not a boolean. Maybe Tuna kernel doesn't have the latest code for setting it to 2, kernel 3.4 has it natively. I'll merge it later to Tuna.

 

 

kernel 3.1 has it too considering it works on the N7. Just poor us stuck down on 3.0.

[Joaquín (joaquinf)]

Thanks for the script with the updated values Chris. I'm using cfq on my n7 and it actually feels better than row judging by animations and swiftkey, I'm gonna use it tomorrow and see how it goes

[Steve (Gingerbread Man)]

I think these latest values are also better on battery. I'm at 68% 8+ off charger, just over an hour screen on, no wifi. I'm impressed! This is data from my gnex btw

[Chris (osm0sis)]

I think it's cool that a little bit from all of us made it into the final values.

 

100/75/5/4 and 15/25 from Zach, the 4 from Aleem's 6/5/4, and Joaquin pointing out 15 didn't work on the N7, resulting in some more testing narrowing it down to 20 or 10, and me adding the 3 and experimenting to come up with 3/12/10, for outcome values of 3/2/15 on the GN and 3/2/10 on the N7.

 

Go team. :D

 

Edit: Update given what we've learned about the new version of row on manta and mako;

 

# row tweaks
echo 100 > /sys/block/mmcblk0/queue/iosched/hp_read_quantum;
echo 75 > /sys/block/mmcblk0/queue/iosched/rp_read_quantum;
echo 5 > /sys/block/mmcblk0/queue/iosched/hp_swrite_quantum;
echo 4 > /sys/block/mmcblk0/queue/iosched/rp_swrite_quantum;
echo 4 > /sys/block/mmcblk0/queue/iosched/rp_write_quantum;
echo 3 > /sys/block/mmcblk0/queue/iosched/lp_read_quantum;
echo 12 > /sys/block/mmcblk0/queue/iosched/lp_swrite_quantum;

echo 10 > /sys/block/mmcblk0/queue/iosched/read_idle;
echo 25 > /sys/block/mmcblk0/queue/iosched/read_idle_freq;
## N4 and N10 have a new version of row with corrected entry for lsq and renamed ri and rif
[ `cat /sys/block/mmcblk0/queue/iosched/lp_swrite_quantum` != "2" ] && echo 2 > /sys/block/mmcblk0/queue/iosched/lp_swrite_quantum;
echo 10 > /sys/block/mmcblk0/queue/iosched/rd_idle_data;
echo 25 > /sys/block/mmcblk0/queue/iosched/rd_idle_data_freq;

:)