[TWEAK][APK][CWM][[Update 2.0.0]] Seeder entropy generator to provide lag reduction

Search This thread

bradman117

Senior Member
Jan 20, 2011
1,534
1,518
27
Idaho, Rexburg
Original Post | CWM
Guys check this out

Best result on Android 4.+
Description
Hey everyone,

So, I was experiencing significant lag as we all do from time to time, and decided I was going to get to the bottom of it.

After tracing and debugging for hours, I discovered the source of 90% of Android's lag. In a word, entropy (or lack thereof).

Google's JVM, like Sun's, reads from /dev/random. For all random data. Yes, the /dev/random that uses a very limited entropy pool.

Random data is used for all kinds of stuff.. UUID generation, session keys, SSL.. when we run out of entropy, the process blocks. That manifests itself as lag. The process cannot continue until the kernel generates more high quality random data.

So, I cross-compiled rngd, and used it to feed /dev/urandom into /dev/random at 1 second intervals.

Result? I have never used an Android device this fast.

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!

Update!
I've built a very simple Android app that bundles the binary, and starts/stops the service (on boot if selected). I'll be adding more instrumentation, but for now, give it a shot! This APK does not modify /system in any way, so should be perfectly safe.

This is my first userspace Android app, so bear with me!

Note that this APK is actually compatible with all Android versions, and all (armel) devices. It's not at all specific to the Captivate Glide.
Quote Original Post link - Click Here




UPDATE: Seeder_v7 is out, as suggested by pepoluan, it now detects for qrngd (built in rngd for Qualcomm Snapdragon-based devices), if it is there, then it will not start as rngd may conflict with it...the rngd binary is also using the latest version (it is turned off when screen is off)...users of previous versions can just flash it over...

INSTALLING
You need init.d support for this!
Download and flash:


How to use this script?:
After flashing, launch terminal emulator and type
Code:
su
seeder

You will get a menu like this:
FBB94.png


NOTE: There will be NO app after flashing! This only installs the necessary binaries and scripts...


For those who cannot install via recovery:
You get a status 0 error -> replace the update-binary in Seeder_v6.zip with one from another zip that works with your device

OR

Use the new installation method! :D

Instructions:
1. Download Seeder_v7_non-CWM.zip from here:
2. Extract the zip, you will get a folder named "install"
3. Place the folder in the root of your sdcard (/sdcard)
4. Launch terminal emulator, type:
Code:
su
cd /sdcard/install
sh install.sh
5. Ignore any error messages (those are only warnings, only happens to current users)
6. You are done! The script will auto-delete the "install" folder as it is not required anymore...

Sample output:
bUDTA.png



UNINSTALLING:
And now for the way to clean up Seeder_7:
Via recovery:
Flash Seeder_v6&7_Uninstall.zip:

Via terminal:
1. Download Seeder_v6&7_Uninstall_non-CWM.zip:
2. Extract it to the root of your sdcard (/sdcard), you should get a file named uninstall.sh
3. Launch terminal emulator and type this:
Code:
su
cd /sdcard
sh uninstall.sh
4. You are done! Everything gets cleaned up, including uninstall.sh...




Flash now works, you can now type in terminal to turn off/on and also easier remove. Up to u if ud like to try. Note" it may drain battery more" so please do not be going all against tweak. Thanks

FLASH THIS ON GINGERBREAD!?!?!(v1.4.0)


Thanks to Zen Arcade for making a flash for Gingerbread! His Post Here!

I took a look at the original CWM package and made the following changes:

1 - swapped in our update-binary
2 - changed the mount command in edify script (not really needed since system is already mounted in gb voodoo CWM recovery)
3 - removed all mount commands from init.d script (not required since you have to have /system mounted just to read the script)

Here's a link to the CWM flashable: http://d-h.st/Kaq

I'm running this on both my Infuses - no problems noted. At work now so will not have a chance to try with games for a couple more hours at least. Only down side I can note is that the rngd binary is about 1MB in size - a small sacrifice if it does eliminate lag events

Note that this package is for GB, but should work fine for 4.x roms as long as /system is mounted as part of recovery startup. Can someone test on a 4.x (CWM9/10) rom by flashing the zip and then checking /system/etc/init.d for a file named 91RNGD or /system/xbin for rngd? I've already tested on GB and it works fine there.

Thanks bradman for posting this - all credit and thanks to the original devs who posted this.
 
Last edited:

dginsd

Senior Member
Jan 23, 2012
278
56
Sorry if this is a n00b question, but if you just install the .apk do you still need to change the permissions or does it take care of it for you?
 

deathblade

Senior Member
Dec 19, 2011
1,503
401
Google Pixel 2 XL
Sorry if this is a n00b question, but if you just install the .apk do you still need to change the permissions or does it take care of it for you?

Is best to just fix Perm to brr safe, easiest way to do so if you just install the app is to go to recovery/advanced/fix permissions and reboot

Sent from my SGH-I997 using xda premium
 

phazeonphoenix

Senior Member
Apr 7, 2010
53
11
I must say, this relatively minor tweak provides a noticeable boost. I'm currently using Liquid Smooth RC9.11 with no further tweaks. After applying this tweak I've noticed faster loading times for a couple games, Google maps is much more responsive to massive view changes, web browsing is snappier, and as stated above almost no redraw delay when returning to the launcher after running a large app (like a game). I must say this under-powered and under-RAMmed little Infuse just keeps getting better and better thanks to all the work the devs here. Keep up the good work!
 

Zen Arcade

Senior Member
Feb 28, 2012
1,345
3,395
Haddonfield, IL
Working CWM Flashable for Infuse GB

I took a look at the original CWM package and made the following changes:

1 - swapped in our update-binary
2 - changed the mount command in edify script (not really needed since system is already mounted in gb voodoo CWM recovery)
3 - removed all mount commands from init.d script (not required since you have to have /system mounted just to read the script)

Here's a link to the CWM flashable: http://d-h.st/Kaq

I'm running this on both my Infuses - no problems noted. At work now so will not have a chance to try with games for a couple more hours at least. Only down side I can note is that the rngd binary is about 1MB in size - a small sacrifice if it does eliminate lag events :)

Note that this package is for GB, but should work fine for 4.x roms as long as /system is mounted as part of recovery startup. Can someone test on a 4.x (CWM9/10) rom by flashing the zip and then checking /system/etc/init.d for a file named 91RNGD or /system/xbin for rngd? I've already tested on GB and it works fine there.

Thanks bradman for posting this - all credit and thanks to the original devs who posted this.

UPDATE - 2012/01/03
I've confirmed the documented improvement in speed at which Maps re-tiles the map display when making big location changes. Still testing other apps. Some games appear a big less laggy, although some disruptive lag events still occur (I suspect due to file system i/o scheduler delays rather than from lack of random/entropy data as addressed with this enhancement). I'll do some benchmarking over the weekend and report back with results.
 
Last edited:

bradman117

Senior Member
Jan 20, 2011
1,534
1,518
27
Idaho, Rexburg
I took a look at the original CWM package and made the following changes:

1 - swapped in our update-binary
2 - changed the mount command in edify script (not really needed since system is already mounted in gb voodoo CWM recovery)
3 - removed all mount commands from init.d script (not required since you have to have /system mounted just to read the script)

Here's a link to the CWM flashable: http://d-h.st/Kaq

I'm running this on both my Infuses - no problems noted. At work now so will not have a chance to try with games for a couple more hours at least. Only down side I can note is that the rngd binary is about 1MB in size - a small sacrifice if it does eliminate lag events :)

Note that this package is for GB, but should work fine for 4.x roms as long as /system is mounted as part of recovery startup. Can someone test by flashing the zip and then checking /system/etc/init.d for a file named 91RNGD or /system/xbin for rngd?
I currently cant test this but if it turns out to work ill put it on OP. i did hear from someone that the biggest difference on GB but i cant say that for y self because i have not tried yet :p
 

bkmo

Senior Member
Jun 25, 2008
1,890
226
10° 5' 59" North, 84° 16' 84" West
Works fine on Scott's CM10. PS shows the rngd process running. Thanks

Note that this package is for GB, but should work fine for 4.x roms as long as /system is mounted as part of recovery startup. Can someone test on a 4.x (CWM9/10) rom by flashing the zip and then checking /system/etc/init.d for a file named 91RNGD or /system/xbin for rngd? I've already tested on GB and it works fine there.

Thanks bradman for posting this - all credit and thanks to the original devs who posted this.



Sent from my SGH-I997 using xda premium
 
  • Like
Reactions: Zen Arcade

bradman117

Senior Member
Jan 20, 2011
1,534
1,518
27
Idaho, Rexburg
Heyyy Scott, check out this guys find

lordvincent 90 posted it..
Originally Posted by zeppelinrox
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:
Code:
busybox sysctl -e -w kernel.random.read_wakeup_threshold=128;
busybox sysctl -e -w kernel.random.write_wakeup_threshold=256;
As you can see, I had doubled the default values - and that's why my entropy_avail was always over 300.

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:
Code:
while :; do cat /proc/sys/kernel/random/entropy_avail; sleep 1;done
In a second command prompt I did the sysctl thing...
I found that write_wakeup_threshold didn't effect entropy_avail at all.

But read_wakeup_threshold is a totally different story

I did
Code:
busybox sysctl -w kernel.random.read_wakeup_threshold=2048
The entropy_avail just started climbing....

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:
Code:
echo 1366 > /proc/sys/kernel/random/read_wakeup_threshold
Or
Code:
busybox sysctl -w kernel.random.read_wakeup_threshold=1366
You can add either of those to any init.d script.
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:
Code:
busybox sysctl -e -w kernel.random.read_wakeup_threshold=1024;
busybox sysctl -e -w kernel.random.write_wakeup_threshold=2048;
That will make it bounce between 3072 max and 2048 min.
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.

lordvincent 90 posted it..
Just adding this, after reading the whole thread here it seems like this may be a simpler solution (and better on battery life)

Post Link -- http://forum.xda-developers.com/showpost.php?p=36208713&postcount=32
 
  • Like
Reactions: qkster

wawaweewa

Senior Member
Jul 9, 2008
927
208
32
lake elsinore
I took a look at the original CWM package and made the following changes:

1 - swapped in our update-binary
2 - changed the mount command in edify script (not really needed since system is already mounted in gb voodoo CWM recovery)
3 - removed all mount commands from init.d script (not required since you have to have /system mounted just to read the script)

Here's a link to the CWM flashable: http://d-h.st/Kaq

I'm running this on both my Infuses - no problems noted. At work now so will not have a chance to try with games for a couple more hours at least. Only down side I can note is that the rngd binary is about 1MB in size - a small sacrifice if it does eliminate lag events :)

Note that this package is for GB, but should work fine for 4.x roms as long as /system is mounted as part of recovery startup. Can someone test on a 4.x (CWM9/10) rom by flashing the zip and then checking /system/etc/init.d for a file named 91RNGD or /system/xbin for rngd? I've already tested on GB and it works fine there.

Thanks bradman for posting this - all credit and thanks to the original devs who posted this.

Anyone tried this?

Btw brad im on jvu saurom and flashed it fix permission but this is what i get
tyvega5e.jpg
 

zipikiki

Senior Member
Tweak

This relatively minor tweak provides a noticeable boost. I'm currently using Liquid Smooth RC9.11 with no further tweaks. After applying this tweak I've noticed faster loading times for a couple games, Google maps is much more responsive to massive view changes, web browsing is snappier, and as stated above almost no redraw delay when returning to the launcher after running a large app (like a game). I must say this under-powered and under-RAMmed little Infuse just keeps getting better and better thanks to all the work the devs here. Keep up the good work!

BR
 
  • Like
Reactions: bigbob_ftw

Top Liked Posts

  • There are no posts matching your filters.
  • 22
    Original Post | CWM
    Guys check this out

    Best result on Android 4.+
    Description
    Hey everyone,

    So, I was experiencing significant lag as we all do from time to time, and decided I was going to get to the bottom of it.

    After tracing and debugging for hours, I discovered the source of 90% of Android's lag. In a word, entropy (or lack thereof).

    Google's JVM, like Sun's, reads from /dev/random. For all random data. Yes, the /dev/random that uses a very limited entropy pool.

    Random data is used for all kinds of stuff.. UUID generation, session keys, SSL.. when we run out of entropy, the process blocks. That manifests itself as lag. The process cannot continue until the kernel generates more high quality random data.

    So, I cross-compiled rngd, and used it to feed /dev/urandom into /dev/random at 1 second intervals.

    Result? I have never used an Android device this fast.

    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!

    Update!
    I've built a very simple Android app that bundles the binary, and starts/stops the service (on boot if selected). I'll be adding more instrumentation, but for now, give it a shot! This APK does not modify /system in any way, so should be perfectly safe.

    This is my first userspace Android app, so bear with me!

    Note that this APK is actually compatible with all Android versions, and all (armel) devices. It's not at all specific to the Captivate Glide.
    Quote Original Post link - Click Here




    UPDATE: Seeder_v7 is out, as suggested by pepoluan, it now detects for qrngd (built in rngd for Qualcomm Snapdragon-based devices), if it is there, then it will not start as rngd may conflict with it...the rngd binary is also using the latest version (it is turned off when screen is off)...users of previous versions can just flash it over...

    INSTALLING
    You need init.d support for this!
    Download and flash:


    How to use this script?:
    After flashing, launch terminal emulator and type
    Code:
    su
    seeder

    You will get a menu like this:
    FBB94.png


    NOTE: There will be NO app after flashing! This only installs the necessary binaries and scripts...


    For those who cannot install via recovery:
    You get a status 0 error -> replace the update-binary in Seeder_v6.zip with one from another zip that works with your device

    OR

    Use the new installation method! :D

    Instructions:
    1. Download Seeder_v7_non-CWM.zip from here:
    2. Extract the zip, you will get a folder named "install"
    3. Place the folder in the root of your sdcard (/sdcard)
    4. Launch terminal emulator, type:
    Code:
    su
    cd /sdcard/install
    sh install.sh
    5. Ignore any error messages (those are only warnings, only happens to current users)
    6. You are done! The script will auto-delete the "install" folder as it is not required anymore...

    Sample output:
    bUDTA.png



    UNINSTALLING:
    And now for the way to clean up Seeder_7:
    Via recovery:
    Flash Seeder_v6&7_Uninstall.zip:

    Via terminal:
    1. Download Seeder_v6&7_Uninstall_non-CWM.zip:
    2. Extract it to the root of your sdcard (/sdcard), you should get a file named uninstall.sh
    3. Launch terminal emulator and type this:
    Code:
    su
    cd /sdcard
    sh uninstall.sh
    4. You are done! Everything gets cleaned up, including uninstall.sh...




    Flash now works, you can now type in terminal to turn off/on and also easier remove. Up to u if ud like to try. Note" it may drain battery more" so please do not be going all against tweak. Thanks

    FLASH THIS ON GINGERBREAD!?!?!(v1.4.0)


    Thanks to Zen Arcade for making a flash for Gingerbread! His Post Here!

    I took a look at the original CWM package and made the following changes:

    1 - swapped in our update-binary
    2 - changed the mount command in edify script (not really needed since system is already mounted in gb voodoo CWM recovery)
    3 - removed all mount commands from init.d script (not required since you have to have /system mounted just to read the script)

    Here's a link to the CWM flashable: http://d-h.st/Kaq

    I'm running this on both my Infuses - no problems noted. At work now so will not have a chance to try with games for a couple more hours at least. Only down side I can note is that the rngd binary is about 1MB in size - a small sacrifice if it does eliminate lag events

    Note that this package is for GB, but should work fine for 4.x roms as long as /system is mounted as part of recovery startup. Can someone test on a 4.x (CWM9/10) rom by flashing the zip and then checking /system/etc/init.d for a file named 91RNGD or /system/xbin for rngd? I've already tested on GB and it works fine there.

    Thanks bradman for posting this - all credit and thanks to the original devs who posted this.
    13
    I stumbled upon this myself a few days ago and have been looking into it... I can easily implement it into my source builds, but want to see how it reacts first before doing so. And btw bradman... CM10.1 is smooth as **** with nothing needed... but if this makes it even better, then thats good to hear. :)
    6
    Zeppelinrox version of this tweak

    Here are a couple CWM flashables which implement the Zeppelinrox option for this tweak and don't run the rngd binary:

    Increase to available entropy range (2048-3096) - http://d-h.st/Ldy

    Maximize (3600+) - http://d-h.st/ulE

    The only one I recommend is the first one. It's unclear to me whether the maximize option allows for regular flushing of the pool. The first one raises the minimum threshold and should prevent most or all blocks on /dev/random.

    Both of these flashables will remove the other versions of this tweak before applying the desired setting.
    6
    So that's a pretty big vote for "snake oil" on the rngd option (#1), especially on current firmwares. :)

    I tend to agree with the assessment that it will not do any harm (other than to make random bits less random). I'm still going to run with the second option on my GB rom for a while longer - mainly because of the info from an android project team member at google who posted here (post #8) that this function was broken in GB:

    http://code.google.com/p/android/issues/detail?id=42265

    The post on the portal also mentions just two places where "get_random_bytes" is called in the kernel. This may be true for AOSP firmwares like CM, but in our Sammy stock kernel all of the following source files contain a call to this function....


    drivers/char/random.c
    drivers/net/wireless/bcm4330/src/dhd/sys/dhd_custom_sec.c
    fs/cifs/cifsencrypt.c [disclaimer: I added this one to my kernel :) ]
    fs/ext2/ialloc.c
    fs/ext4/ialloc.c
    kernel/panic.c
    net/core/dev.c
    net/core/flow.c
    net/core/neighbour.c
    net/core/request_sock.c
    net/ipv4/tcp.c
    net/ipv4/tcp_output.c
    net/ipv6/addrconf.c
    net/netfilter/nf_conntrack_core.c
    net/netfilter/nf_conntrack_expect.c
    net/netfilter/xt_connlimit.c


    All this said, I'm still not convinced that either tweak will eliminate lag, but at least the zeppelinrox option preserves the standard randomness mechanism while raising the minimum amount of bits available should a block condition otherwise occur. At a minimum, (for me anyway) this was a fun diversion that taught me a bit more about the Linux underpinnings of Android... so there's that. :)
    4
    Regarding entropy512, note that the maximum size of the entropy pool is 4096 bits. This is equivalent to 512 bytes.... :)

    Maybe he's known about this all along.........

    After you implement one of the tweaks you will see a change in minimum available bits. With the original tweak, it jumps up to a big number and stays high with some volatility. I suspect this is the rngd binary, which force feeds /dev/random, fighting with the standard flushing mechanism.

    The zeppelinrox options will result in number of available bits slowly growing (occuring faster if you use the phone while watching) then staying high. The maximize option will go to about 3600, then slowly increment by 10-11 until it approaches a max somewhat less than 4096. The increase option will grow to 3000+ then bounce between 2000-3000 as the standard read/write/flush process occurs. This is why I recommend the "increase" option if you are inclined to run this tweak.

    Regardless, impact is minimal except for battery drain from rngd option.... and benefit is unclear under most circumstances. I'm testing on GB as that seems to be the one place where it might do some good. Those seeing a benefit on 4.x firmwares may just be seeing the improvement a reboot brings conflated with a certain amount of confirmation bias. :)

    Sent from my SAMSUNG-SGH-I997 using xda premium
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone