[APK] Seeder 2.0.0 entropy generator to provide significant lag reduction

Search This thread

orangekid

Sr. Mod / Mod Committee / RC-RT Committee
Staff member
Apr 10, 2009
14,778
9,178
Didn't read all the replies, so someone may have already mentioned this...
The correct way of fixing the problem is changing the source of the program that's using /dev/random to use /dev/urandom, instead.
It's a well-known "issue" that /dev/random is blocking and doesn't usually have much data for you to get from it. Most of the time you shouldn't need so much truly random data.. but if you do, it's probably safer to feed it from other random sources: noise from sound card input, radio receivers (wifi/bt/gps), temperature fluctuations, etc.


That is a good solution for app developers, not for users. This is a good solution for users because for every app that does use /random instead of /urandom now has data to "feed" off. A better solution for users would be something akin to permissions fixer that actually goes through every app and finds/changes that command line to point to /urandom but of course I don't know that such a script could be devised. For now this is a good solution until a better one is found, but, for older devices especially, this is an awesome tweak that seems to be making a lot of people happy.

Why it works exactly technically speaking is actually of secondary importance and it would be better if we tried to help OP figure it out than to blindly opine on the matter, but the fact of the matter is that the seeder IS improving some performance on devices and it does not appear to just be OCing, OVing, or just scaling a governor or an IO scheduler, so it is certainly worth looking into.

Inferring that the OP is less than honest or nefarious or just acting condescendingly toward him or this tweak is puerile and in my view goes against the atmosphere this forum tries to convey, which is to actually help real development and figure out why things operate as they do. He's made some kind of breakthrough, now let's enjoy it and dissect it instead of just stating why it theoretically shouldn't be improving performance. It may be under the hood, it may be below the Dalvik VM level, or whatever the actual cause may be.
 

brianoh

Member
Jan 4, 2013
6
0
Hi, was wondering if anyone could help me. I flashed "Seeder_v5.zip" and have noticed a hit in my battery life. Is there a way to unflash it or undo it?
 

lupp0l0

Senior Member
Aug 12, 2010
82
17
I do believe this is a better alternative. Attached is a flashable zip, requires Busybox and a kernel with init.d support. It's a simple init.d script containing the following:
Code:
#!/system/bin/sh
busybox sysctl -e -w kernel.random.read_wakeup_threshold=1366;
You can get rid of it by simply erasing the 01randent file from /system/etc/init.d.
I don't know whether or not I'm crazy, but the UI does feel smoother for me.

I think you're not crazy. I've got performance improvements setting read_wakeup_threshold=768.
I will try other values, for now I'm satisfied with 768

Sent from my LG-P970 using xda app-developers app
 

goodtimes50

Senior Member
Oct 15, 2012
676
136
OKC
I do believe this is a better alternative. Attached is a flashable zip, requires Busybox and a kernel with init.d support. It's a simple init.d script containing the following:
Code:
#!/system/bin/sh
busybox sysctl -e -w kernel.random.read_wakeup_threshold=1366;

I flashed a script from earlier in the thread that set it to 1376. Is there a reason you went with 1366? Is it likely to matter?
 

lambgx02

Senior Member
Jul 26, 2008
441
3,208
Montreal
Hey guys,

Just wanted to say a few things -

1. My initial analysis (dalvik reading /dev/random) does indeed not apply on ICS, Jellybean, etc.
2. Nevertheless, it seems that rngd does have a significant effect on these builds for some people, including me.
3. I'm going through the kernel's RNG code right now trying to figure out if perhaps there's some lock contention, or something else funky going on. I have entropy debugging turned on, and there are a *lot* of nonblocking reads going on, constantly.
4. Perhaps it is just kicking the governor, but I don't see any change to time_in_state with it running. I suspect it really has something to do with the input entropy pool.

I never expected Seeder to take off like this; it's a little scary. I initially published a build, and had very positive feedback on XDA, so decided to put something on the marketplace. Though I've been a *nix admin and coder for a while, this is my first Android app.

It doesn't seem to work the way I thought it did on later Android builds, and I will get to the bottom of this.
 

zeppelinrox

Senior Member
Dec 21, 2010
9,374
21,590
IN THE FREAKIN' OP
I do believe this is a better alternative. Attached is a flashable zip, requires Busybox and a kernel with init.d support. It's a simple init.d script containing the following:
Code:
#!/system/bin/sh
busybox sysctl -e -w kernel.random.read_wakeup_threshold=1366;
You can get rid of it by simply erasing the 01randent file from /system/etc/init.d.
I don't know whether or not I'm crazy, but the UI does feel smoother for me.
I'm inclined to think that its due to less background activity.
Wonder if logcats can turn up anything...

Oh if you don't have busybox you can do:
echo 1376 > /proc/sys/kernel/random/read_wakeup_threshold
I flashed a script from earlier in the thread that set it to 1376. Is there a reason you went with 1366? Is it likely to matter?
ah I started using 1376 just because its a multipe of 16 :p
 
Last edited:

emd2009

Senior Member
Jun 3, 2007
739
91
I do believe this is a better alternative. Attached is a flashable zip, requires Busybox and a kernel with init.d support. It's a simple init.d script containing the following:
Code:
#!/system/bin/sh
busybox sysctl -e -w kernel.random.read_wakeup_threshold=1366;
You can get rid of it by simply erasing the 01randent file from /system/etc/init.d.
I don't know whether or not I'm crazy, but the UI does feel smoother for me.

will try this thanks
 
  • Like
Reactions: demolatorul

LeoPosas

Senior Member
Dec 12, 2011
2,235
4,831
San Pedro Sula
about.me
OnePlus 6
Hey guys,

Just wanted to say a few things -

1. My initial analysis (dalvik reading /dev/random) does indeed not apply on ICS, Jellybean, etc.
2. Nevertheless, it seems that rngd does have a significant effect on these builds for some people, including me.
3. I'm going through the kernel's RNG code right now trying to figure out if perhaps there's some lock contention, or something else funky going on. I have entropy debugging turned on, and there are a *lot* of nonblocking reads going on, constantly.
4. Perhaps it is just kicking the governor, but I don't see any change to time_in_state with it running. I suspect it really has something to do with the input entropy pool.

I never expected Seeder to take off like this; it's a little scary. I initially published a build, and had very positive feedback on XDA, so decided to put something on the marketplace. Though I've been a *nix admin and coder for a while, this is my first Android app.

It doesn't seem to work the way I thought it did on later Android builds, and I will get to the bottom of this.

One question, recommendable the APK or the binary called from script?
 

Yze

Senior Member
Feb 2, 2006
353
55
im guessing busybox MUST be installed for the seeder apk file to work correctly? or no?

this command: 'watch -n 1 cat /proc/sys/kernel/random/entropy_avail' glitches for me.. so i tried: 'pgrep rngd' and the values returned are:

250
1954

does that mean its not working/running correctly?
 
Last edited:

rmagruder

Senior Member
Aug 5, 2009
323
59
Hey guys,

Just wanted to say a few things -

1. My initial analysis (dalvik reading /dev/random) does indeed not apply on ICS, Jellybean, etc.
2. Nevertheless, it seems that rngd does have a significant effect on these builds for some people, including me.
3. I'm going through the kernel's RNG code right now trying to figure out if perhaps there's some lock contention, or something else funky going on. I have entropy debugging turned on, and there are a *lot* of nonblocking reads going on, constantly.
4. Perhaps it is just kicking the governor, but I don't see any change to time_in_state with it running. I suspect it really has something to do with the input entropy pool.

I never expected Seeder to take off like this; it's a little scary. I initially published a build, and had very positive feedback on XDA, so decided to put something on the marketplace. Though I've been a *nix admin and coder for a while, this is my first Android app.

It doesn't seem to work the way I thought it did on later Android builds, and I will get to the bottom of this.

First of all, no matter what this all turns out to be, I think I speak for a lot of people who appreciate your work. There's a lot of haters, please ignore them. They are outnumbered by those that are happy you're doing this research, wherever it leads.

Secondly, I think the #1 question on my mind is....who is doing all this reading? Over on code.google.com, it is being emphasized that nothing except Wi-Fi AP, SSL ticket generation and one other thing I forget, are doing anything with dev/random. So the claim is that there's NO reason to be exhausting this pool. Another dev said that it is the ASLR randomization in Linux being called from the Kernel and enabled in 4.1+ of Android, but again, denying that could be exhausting the pool. So, if someone is doing tons of reads of dev/random, or dev/urandom, depending, what on earth is doing it and why is that so hard to find? :(

You've now intrigued Steve Kondik over at code.google.com, so I'm going to be watching with popcorn in hand as this investigation continues.

Thanks!


Sent from my Nexus 7 using Tapatalk HD
 
Last edited:

lambgx02

Senior Member
Jul 26, 2008
441
3,208
Montreal
One question, recommendable the APK or the binary called from script?

Once I'm satisfied I know why it still works, I'm going to build a new version that suspends/resumes the daemon on screen off/on events to eliminate any theoretical battery drain. So, for end-users I would suggest the APK; I'll of course be posting them to this thread.
 

OmegaBlaze

Senior Member
Dec 24, 2009
1,907
634
www.twitter.com

Hmm, can't really say the difference is night and day. Then again if you're running at 200MHz, it's not surprising that there's lag in XDA scrolling either way.

Sent from my Galaxy Note!

That's how i feel. If the difference isn't night and day, it doesn't work. However, if the app does work, my theory is that it will have no choice but to show some slight of difference if the kernel is set that low.

Someone give me another test and i'll do it!
 
Last edited:

o0BlacknesS0o

Senior Member
Mar 28, 2012
2,793
1,924
Fincastle, VA
I'm inclined to think that its due to less background activity.
Wonder if logcats can turn up anything...

Oh if you don't have busybox you can do:
echo 1376 > /proc/sys/kernel/random/read_wakeup_threshold
ah I started using 1376 just because its a multipe of 16 :p

What about write_wakeup_threshold.... should that be altered as well... Mine is currently set at 256...read_wakeup_threshold was originally 128

Samsung Galaxy SIII powered by CleanROM
 

Eomo

New member
Mar 8, 2011
1
0
Bought the app anyways!

Hey dude, bought the app in the app store anyways, just to support you. Keep up the good work!
 

nowster

Senior Member
Dec 30, 2012
425
136
Has anyone tried using anything like the following from an adb shell?

Code:
#!/system/bin/sh
while true
do
  busybox dd if=/dev/urandom of=/dev/random bs=1024 count=1 2>/dev/null
  sleep 2
done
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2505
    Hey everyone,

    Version 2.0.0 released!

    This version introduces performance tuning, power management control, and an optional MMC I/O queue extension/timing change.

    For those of you who have seen reboots / black screens that seem to be caused by Seeder, I suspect it may be due to the power management implemented in previous versions. Disabling power management (by unchecking "Suspend RNG service while screen off") may help. In my testing, battery impact was negligible (less than 2% per 24h).

    The performance profiles are Light, Moderate, and Aggressive, and they control how frequently rngd wakes. The default configuration (Light) is unchanged from previous versions. Moderate and Aggressive may impact battery life (slightly), but may also help on devices where the entropy pool is drained quickly and often.

    Last but not least, the "Extend I/O queue" option increases the nr_requests on MMC devices to 1024, and increases the dirty page expiry time, allowing more outstanding writes to accumulate. This may allow the I/O scheduler to make better decisions and combine more writes; some users have reported an improvement under heavy I/O.

    Feedback appreciated!

    ---

    On some (older) versions of Android, the JVM (and other components) often read random data from the blocking /dev/random device. On newer builds, this problem has been solved, yet depletion of the input entropy pool still seems to slow devices.

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

    Result? Significant lag reduction (for some people)! :good:

    Note - if you want to try it, you must be running a rooted device, and you only need to install one of the APKs (latest version is best). Then, just open it, and turn it on. The other files (patches / .zips) are intended for recompiling, packaging, and init.d integration. If you uninstall the app, either turn off rngd first (open, and click the on/off button), or reboot afterwards; the UI does not presently kill the daemon on uninstallation.

    For more information on using the .zip flashing method, see Ryuinferno's post here:

    http://xdaforums.com/showpost.php?p=36479461&postcount=1924

    FAQ
    Q: Do I need the .apk or the .zip?
    A: The easiest method is simply installing the latest .apk, attached below. You do not need to use the patch or the .zip file.

    Q: What is the patch for?
    A: The patch file contains the source differences needed to recompile the Seeder version of the rngd binary. You only need it if you want to recompile rngd yourself.

    Q: What is the .zip file for?
    A: The .zip file contains the latest rngd binary. It is intended for ROM builders or those who want to build their own CWMR packages.

    Q: Seeder keeps shutting down! Does this mean I have to restart it?
    A: The Seeder UI is only used to configure and start/stop the RNG service, which runs in the background. The RNG service is not visible from Android, since it is a native Linux process. You can terminate the UI at any time, and the service will continue running.

    Q: Does seeder cause excessive battery drain?
    A: Seeder 1.2.7 introduced an RNG service power-saving mode. The process automatically suspends whenever the screen is off. The code is actually in the rngd native binary, so suspend/resume events happen independently of the UI; you can see it in action by attaching to the running process with strace. This means that battery drain while the screen is off is highly unlikely.

    While the screen is on, the RNG service simply polls a file descriptor every second, and, when needed, injects a small amount of random data into /dev/random (and calls an ioctl). It's unlikely that this would present enough load to trigger a CPU governor state change at 10mhz (let alone 200mhz), so it shouldn't impact battery life. Having said that, I have received sporadic reports that it does reduce battery life on some devices. They may be coincidental (other software installed at the same time), or due to extra device use while testing. Or, they may be real. If you think your battery drain has increased, shoot me a PM!

    Q: How can I see the RNG service Linux process?
    A: In a terminal, type: ps | grep rngd

    Q: How do I uninstall the .apk?
    A: Launch Seeder, and stop the RNG service. Then, uninstall the app as you normally would. Alternatively, uninstall the app, and reboot.

    Q: Is seeding /dev/random with /dev/urandom safe?
    A: Seeding /dev/random with PRNG-derived data does reduce the quality of its random data. However, it's worth noting that nearly all major OSes except Linux do this. Linux is one of the very few to offer a blocking RNG device. And, at least as of ICS, Dalvik doesn't even read /dev/random, so there is little difference anyway.

    Updates
    There has been a lot of controversy about Seeder/rngd. In newer versions of Dalvik, nothing touches /dev/random, and yet many users (including myself) still notice a lag reduction. There are theories ranging from kernel lock contention to UI polling load when crediting the entropy pool to simply kicking the governor. And many who believe it's all placebo. I'm trying my best to figure out what exactly is happening, and others are as well.

    Someone asked how I arrived at the conclusion I did when I started the thread back in November, and I posted this; I think it might be better served here:

    A while back one of the webapps I was hosting on Tomcat (server-side) was experiencing some inexplicable latency and while stracing java I saw it frequently hanging on read()'s from /dev/random. I checked the available entropy, and it was constantly under 250 or so. It was a VM, no HWRNG, so I decided to use rngd to push urandom->random.

    Dropped session creation times under load from 5-10 seconds to less than a second.

    It's worth noting that Linux is one of very few OSes that have a blocking RNG device. Free/OpenBSD, Windows, etc.. essentially only provide urandom. It's generally considered secure, even for long-term crypto keys, so long as the initial seed is big (and random) enough.

    Checked on my device, and saw a few processes grabbing /dev/random. /proc/sys/kernel/random/entropy_avail reporting depleted input pool. Figured it was worth a shot, so I rebuilt rngd for arm (with a few patches, linked on first page), and tried it out. It made a significant difference. Posted it up on this thread, and had a lot of positive feedback. Wanted to get into Android development, so figured.. why not wrap a little UI around it. More positive feedback, so I threw it on the market as well.

    I had no idea it would take off like this and was shocked when I saw it Thursday morning. I'm in the awkward position now of explaining why it seems to work for some people, and not for others, especially given the fact Dalvik doesn't have references to /dev/random as of ICS. Theories abound, but it looks like it might be an issue of polling the UI for input events when the entropy pool drops (which never happens so long as rngd is running).

    I'm doing this as a hobby. I'm a *nix admin by trade, and can only spend time working on this stuff on evenings and weekends, and the last few weeks have been kinda nuts.

    I want to stress to everyone that:

    a) It doesn't work the way I thought it did on later Android builds, but it does reduce latency for me and many others even on these builds,
    b) I'm offering (and always will offer) Seeder for free to everyone on XDA,
    c) Like I say in the market description, if anyone has purchased it and it isn't working, PLEASE email me for a refund (and let me know what device you're on if you're willing).

    I was one of the first to root the Captivate glide (my first Android phone), and submitted the A2DP bitpool patch; I was active in the n900 community. I hope everyone understands that I'm doing my best here!


    I hope the technique proves useful to people, and if there is in fact contention at the kernel level, I hope it's solved so we all benefit.

    Version 2.0.0 attached. No changes.

    Version 2.0.0b1 attached. New performance profile selector, I/O queue extender, and power saving control. Improved root checking.

    Version 1.4.0 attached. Major refactoring. Service control now fully asynchronous.

    Version 1.3.1 attached. No changes from 1.3.1-beta.

    Version 1.3.1-beta released. New root check method during ANR-sensitive code.

    Version 1.3.0 attached. Proper IntentServices for process control, and notification on upgrade / loss of root / autostart failure.

    Version 1.2.9 attached. Yet another update to the upgrade/autostart code.

    Version 1.2.8 attached. Asynchronous startup of rngd during boot; this should solve the remaining autostart problems some users have reported.

    Version 1.2.7 released. This version introduces a much more efficient suspend-on-sleep mode for rngd.

    Version 1.2.6 released. This version reverts the suspend-on-sleep rngd change which may have been contributing to new latency. I'm sorting out a better way of implementing it.

    Version 1.2.5 released. This version should fix the autostart failure some users have seen.

    Version 1.2.4 released. This version implements a progress bar displaying your currently available entropy, as well as automatic rngd restart on upgrade.

    Version 1.2 released. This version implements rngd suspend-on-sleep, and contains minor user interface updates, more robust process and superuser checks, and a new icon (thanks Nathanel!)

    Version 1.1 released. This version uses the release signature, so you will need to uninstall the old XDA version first!

    This version fixes the issue some users were seeing on later Jellybean ROMs, where the UI would misreport the RNG service status.

    Caveats
    • There is a (theoretical) security risk, in that seeding /dev/random with /dev/urandom decreases the quality of the random data. In practice, the odds of this being cryptographically exploited are far lower than the odds of someone attacking the OS itself (a much simpler challenge). It's worth noting that as of ICS, Dalvik uses /dev/urandom exclusively, anyway, and that Linux is one of very few modern operating systems that even offer a blocking RNG device to begin with.
    • Support for rngd suspend-on-sleep was added to Seeder 1.2. It should no longer impact battery life while the device is asleep.
    • There has been a large amount of speculation on why/if this actually improves performance on ICS+ devices. I'm continuing to investigate and will post updates to this thread.

    If you try it, let me know how it goes.

    ROM builders - feel free to integrate this into your ROMs (either the .apk / application, or just the rngd binary called from init.d)!

    If anyone's interested, I've launched a paid app on the Play store for non-xda users. As I add features I'll post the new versions here as a thanks to you guys (and xda community at large for being such a great resource). But if anyone's interested in the market's auto-update feature, just thought I'd mention it. :)

    Cheers! :highfive:
    101
    Seeder v7 (script)

    Before doing anything, please read the first post of this thread to understand how this thing functions!
    Read it here: First post


    First things first I am not the OP but things need to be sorted out...Ok...this thread is starting to get more and more attention, which is good because with more people to test things out, the more feedbacks and the more improvements can be done...however, the thread is now cluttered by tons on unhelpful posts, like "how to use this", "do I need root" etc...useful posts get pushed wayyy behind, until it is hard for people who are really trying to discuss to keep track...so I am here to answer the basic questions:

    Do you need root for the app?:
    Yes

    Can it work on xxx device?:
    Yes, as long as your device is arm based

    Where to download the app?:
    Here: http://xdaforums.com/attachment.php?attachmentid=1640660&d=1358063993
    Or search Play Store for a donate version...
    The other 2 attachments are the rngd binary and a diff patch, which are not really required for end users...

    How do I know that it is working?
    Prior to starting seeder entropy generator through the app (v1.2.4 onwards), the bar below will only show numbers around 100-200++. After you start it, if the bar fills up and the value shoots up to 4000++, then it is working.

    Do I have a risk of bricking my device?
    No because the app won't modify system files at all...anything just uninstall...
    For the zip, it only adds files to your system partition...does not modify any, so if you want to stop using this, you can disable it via the extended menu script...

    It does not do anything/It is placebo/I see no improvements/It is awesome!/Wow!:
    Well, this is not constructive or helpful...NOT AT ALL...keep in mind that this is still a WIP...research and discussions are still going on...if it is not working or you feel no change or a great improvement, please describe more and explain...which a lot of others are already doing so...:)...keep it up!


    Seems that certain people are so bugged by the app...so...for those who prefer to run this via a script and init.d, read on...(the script works the same as the app, but with a few extra features)


    =======================================================================================================================
    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...
    73
    First things first I am not the OP but things need to be sorted out...Ok...this thread is starting to get more and more attention, which is good because with more people to test things out, the more feedbacks and the more improvements can be done...however, the thread is now cluttered by tons on unhelpful posts, like "how to use this", "do I need root" etc...useful posts get pushed wayyy behind, until it is hard for people who are really trying to discuss to keep track...so I am here to answer the basic questions:

    Do you need root for the app?:
    Yes

    Can it work on xxx device?:
    Yes, as long as your device is arm based

    Where to download the app?:
    Here: http://xdaforums.com/attachment.php?attachmentid=1477944&d=1352786461
    Or search Play Store for a donate version...
    The other 2 attachments are the rngd binary and a diff patch, which are not really required for end users...

    How to check whether it is working or not?:
    In terminal emulator, type
    Code:
    watch -n 1 cat /proc/sys/kernel/random/entropy_avail
    You should get values around 3000++ to 4000++...
    Sometimes this command glitches, so if it does not work, please use:
    Code:
    pgrep rngd
    It should return a value...

    Set on boot does not work?:
    It does, just that the app does not show it properly...it is a known bug...to really confirm, use the terminal emulator method above...

    Do I have a risk of bricking my device?
    No because the app won't modify system files at all...anything just uninstall...
    For the zip, it only adds files to your system partition...does not modify any, so if you want to stop using this, you can disable it via the extended menu script...

    It does not do anything/It is placebo/I see no improvements/It is awesome!/Wow!:
    Well, this is not constructive or helpful...NOT AT ALL...keep in mind that this is still a WIP...research and discussions are still going on...if it is not working or you feel no change or a great improvement, please describe more and explain...which a lot of others are already doing so...:)...keep it up!


    For more answers, read this post by my pal pepoluan...:D
    http://xdaforums.com/showpost.php?p=36234571&postcount=444

    Seems that certain people are so bugged by the app...so...for those who prefer to run this via a script and init.d, read on...(the script works the same as the app, but with a few extra features)

    =======================================================================================================================
    UPDATE: Seeder_v6 is out, I improved the detection of whether rngd is running or not (the previous method was not that accurate), and I removed unnecessary lines...previous users can just flash over...

    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_v6_non-CWM.zip from here: http://www.androidfilehost.com/?fid=9390248398092764098
    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



    And now for the way to clean up Seeder_v6:
    Via recovery:
    Flash Seeder_v6_Uninstall.zip:

    Via terminal:
    1. Download Seeder_v6_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...

    NOTE: Please link back to this post if you want to answer someone's question or share it elsewhere, so that people can get sufficient info and repeated answers do not have to be posted...thank you...:)
    63
    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 :cool:

    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 :p

    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.
    62
    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'!

    A while back one of the webapps I was hosting on Tomcat (server-side) was experiencing some inexplicable latency and while stracing java I saw it frequently hanging on read()'s from /dev/random. I checked the available entropy, and it was constantly under 250 or so. It was a VM, no HWRNG, so I decided to use rngd to push urandom->random.

    Dropped session creation times under load from 5-10 seconds to less than a second.

    It's worth noting that Linux is one of very few OSes that have a blocking RNG device. Free/OpenBSD, Windows, etc.. essentially only provide urandom. It's generally considered secure, even for long-term crypto keys, so long as the initial seed is big (and random) enough.

    Checked on my device, and saw a few processes grabbing /dev/random. /proc/sys/kernel/random/entropy_avail reporting depleted input pool. Figured it was worth a shot, so I rebuilt rngd for arm (with a few patches, linked on first page), and tried it out. It made a significant difference. Posted it up on this thread, and had a lot of positive feedback. Wanted to get into Android development, so figured.. why not wrap a little UI around it. More positive feedback, so I threw it on the market as well.

    I had no idea it would take off like this and was shocked when I saw it Thursday morning. I'm in the awkward position now of explaining why it seems to work for some people, and not for others, especially given the fact Dalvik doesn't have references to /dev/random as of ICS. Theories abound, but it looks like it might be an issue of polling the UI for input events when the entropy pool drops (which never happens so long as rngd is running).

    I'm doing this as a hobby. I'm a *nix admin by trade, and can only spend time working on this stuff on evenings and weekends, and the last few weeks have been kinda nuts.

    I want to stress to everyone that:

    a) It doesn't work the way I thought it did on later Android builds, but it does reduce latency for me and many others even on these builds,
    b) I'm offering (and always will offer) Seeder for free to everyone on XDA,
    c) Like I say in the market description, if anyone has purchased it and it isn't working, PLEASE email me for a refund (and let me know what device you're on if you're willing).

    I was one of the first to root the Captivate glide (my first Android phone), and submitted the A2DP bitpool patch; I was active in the n900 community. I hope everyone understands that I'm doing my best here!