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:
Select 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:
Select 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:
Select 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:
Select Code
echo 1366 > /proc/sys/kernel/random/read_wakeup_threshold
Or
Code:
Select 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:
Select 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.