Now I find any research interesting and maybe you were so excited you wanted to share the result first.
But as it doesn't work for me and people asked me if it was placebo or not, I'm curious and would be please to read your original analysis, you know the tracing effort you made, with values measured before/after.
Hi lambgx02!
Interesting research.
I'm afraid your application provide no perceptible improvement on my first test device, Samsung Galaxy Note II / Jelly Bean.
It is generally one of the smoothest device out there currently, but it still drops FPS in many places.
Where I'm noticing no improvement (and I would like some):
- Google+ app posts scrolling while loading content not already in cache. Meaning affecting most scrolling operations
- Gmail app during large scrolling, same thing when loading a few things in background.
- Maps. Still very much drops frames when loading tiles. So obvious it's almost insulting on high end device (for years)
Now I find any research interesting and maybe you were so excited you wanted to share the result first.
But as it doesn't work for me and people asked me if it was placebo or not, I'm curious and would be please to read your original analysis, you know the tracing effort you made, with values measured before/after.
Also, if it improves something (even-tho it's not solving the dropped frames issue completely, there's many other aspects) I'm sure the result of this research could make it into AOSP and every future devices.
Thank you!
What seems to work for me is installing Busy Box as somebody recommended. Just use normal install.I'm having it. And more people are. Look here:
http://xdaforums.com/showpost.php?p=36229159&postcount=353
My device: Galaxy Nexus
Rom: Stock 4.2.1
Root: SuperSU (updated)
Confirmed it is allowed to run as root!
Any ideas?
Posted this a few pages ago... anybody test?So I did a bit of digging and a bit of research and a bit of testing.
I really dunno if the tweak makes that big of an effect but I did discover a nice trick to have a nice fat entropy_avail with zero overhead.
One of the first pages I skimmed was http://linux.die.net/man/4/random which mentioned at the bottom these other files:
read_wakeup_threshold contains the number of bits of entropy required for waking up processes that sleep waiting for entropy from /dev/random.
write_wakeup_threshold contains the number of bits of entropy below which we wake up processes that do a select() or poll() for write access to /dev/random.
Normally, read_wakeup_threshold is 64 and write_wakeup_threshold is 128
I also wondered why most users report that their entropy_avail was by default in the 200ish range while mine was always by default over 300.
I had also found this page at linuxinsight. I had used that site alot when researching Kick Ass Kernelizer's sysctl tweaks.
So I thought, hey I wonder if I can use sysctl to set good values and low and behold, I looked in my script and I already have settings for both lol:As you can see, I had doubled the default values - and that's why my entropy_avail was always over 300.Code:busybox sysctl -e -w kernel.random.read_wakeup_threshold=128; busybox sysctl -e -w kernel.random.write_wakeup_threshold=256;
So I decided to mess with sysctl a bit.
Connected the phone to the laptop.
In one command prompt I watched the entropy_avail with this one liner:In a second command prompt I did the sysctl thing...Code:while :; do cat /proc/sys/kernel/random/entropy_avail; sleep 1;done
I found that write_wakeup_threshold didn't effect entropy_avail at all.
But read_wakeup_threshold is a totally different story
I didThe entropy_avail just started climbing....Code:busybox sysctl -w kernel.random.read_wakeup_threshold=2048
All the way up to 3600+ and just stayed there. Never went down at all.
Actually, the more I did stuff with the phone, the faster the level would climb.
So it would never go down and would never get used.
I thought well maybe I should lower it so it does get used.
I kept lowering read_wakeup_threshold until it got down to 1200 and finally entropy_avail dropped to 2400+ and kept climbing until 3600 and then would drop to 2400 immediately and up again and so on...
I played with different values.
Setting it to 1000... entropy would go up to 3000 and then drop to 2000 and up to 3000 again....
Setting to 750.... entropy would go up to 2250 and drop to 1500 and up to 2250 again...
So the pattern is:
max entropy_avail=read_wakeup_threshold * 3
min. entropy_avail=read_wakeup_threshold * 2 (ie. read_wakeup_threshold * 3 - read_wakeup_threshold)
So it builds up 3 times the read_wakeup_threshold and then when it hits that limit, it drops the value of read_wakeup_threshold.
If you want to lock it it at the highest possible value (4096), you'd do:OrCode:echo 1366 > /proc/sys/kernel/random/read_wakeup_threshold
You can add either of those to any init.d script.Code:busybox sysctl -w kernel.random.read_wakeup_threshold=1366
However, on my device, it won't go over 3600 so you can test for yourself how high yours will go.
If all you can get is 3600ish just go with 1200 (ie. 3600/3)
In Kick Ass Kernelizer I'm gonna make it like so:That will make it bounce between 3072 max and 2048 min.Code:busybox sysctl -e -w kernel.random.read_wakeup_threshold=1024; busybox sysctl -e -w kernel.random.write_wakeup_threshold=2048;
I'm making write_wakeup_threshold twice the amount of read_wakeup_threshold simply because that's what it is by default.
But hey, maybe I can save battery life if I make it 1280 just so it stays locked in at 3600+ and it doesn't have to keep rebuilding entropy_avail lol
So conclusion is: since there is a definite pattern on how entropy was being built up to a pre-determined level and dropped to a pre-determined level, it wasn't actually being used. That's just how it's programmed.
If the setting isn't there to "hold" all the entropy, it just drops/flushes it and force feeding it entropy won't make it not spit it out
So at least I found the setting that will make it hold it in lol
Maybe somebody would like to give it a try and test to see if it actually saves battery by setting read_wakeup_threshold to 1366.
busybox sysctl -e -w kernel.random.read_wakeup_threshold=1366;
I flashed this file: http://www.androidfilehost.com/?fid=9390248398092763238
on my Galaxy nexus, stock but only rooted and I rebooted, but I don't see any difference. Aren't you supposed to get an app that toggles this hack on/off? I didin't get this app installed when I flashed the .zip file.
You have to go to terminal emulator (if you don't have it just download it from play store) and put
SU
(enter)
seeder
How to install it ? there is three files in down section, the OP should write a how to install point...
Hi supercurio,
have you monitored your entropy while doing those tasks?
watch -n 1 cat /proc/sys/kernel/random/entropy_avail
I have used the original file on my Nexus 4 and have always >140 available, even when using Maps.
I guess when it reaches 0 it produces a lag, so the N4 is fast enough to recalculate it, I guess the Note 2 in your case is also fast enough, thats why you don't see much improvement.
Result? I have never used an Android device this fast. :good:
It is literally five times faster in many cases. Chrome, maps, and other heavy applications load in about 1/2 a second, and map tiles populate as fast as I can scroll. Task switching is instantaneous. You know how sometimes when you hit the home button, it takes 5-10 seconds for the home screen to repopulate? Yeah. Blocking on read of /dev/random. Problem solved. But don't take my word for it .. give it a shot!
Hi, I installed the apk on my Xoom running EOS4 #134 and it seems to be working and doing its job. However I want to ask does this mean the app will prevent my device from deep sleep?
Sent from my MZ601 using XDA Premium HD app
It does not hold a wakelock, so it shouldn't have a big impact, but let me know if you think it's causing problems.
su
seeder
su
cd /sdcard/install
sh install.sh
su
cd /sdcard
sh uninstall.sh
watch -n 1 cat /proc/sys/kernel/random/entropy_avail
pgrep rngd
su
seeder
su
cd /sdcard/install
sh install.sh
su
cd /sdcard
sh uninstall.sh
busybox sysctl -e -w kernel.random.read_wakeup_threshold=128;
busybox sysctl -e -w kernel.random.write_wakeup_threshold=256;
while :; do cat /proc/sys/kernel/random/entropy_avail; sleep 1;done
busybox sysctl -w kernel.random.read_wakeup_threshold=2048
echo 1366 > /proc/sys/kernel/random/read_wakeup_threshold
busybox sysctl -w kernel.random.read_wakeup_threshold=1366
busybox sysctl -e -w kernel.random.read_wakeup_threshold=1024;
busybox sysctl -e -w kernel.random.write_wakeup_threshold=2048;
Ok, I have a question for the OP:
I would like to know your through process that led up to the development of this patch. Was this just instinct or did you have a hint? Did you use a profiler of some sort? I'm just incredibly curious how on earth you arrived at the 'problem' before developing your 'solution'!