Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

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

OP lambgx02

4th January 2013, 10:50 PM   |  #1181  
orangekid's Avatar
Forum Moderator
Thanks Meter: 3,197
 
10,377 posts
Join Date:Joined: Apr 2009
More
Quote:
Originally Posted by Fry-kun

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.
4th January 2013, 10:57 PM   |  #1182  
OmegaBlaze's Avatar
Senior Member
Thanks Meter: 266
 
998 posts
Join Date:Joined: Dec 2009
As promised!
The Following 4 Users Say Thank You to OmegaBlaze For This Useful Post: [ View ]
4th January 2013, 10:58 PM   |  #1183  
Junior Member
Thanks Meter: 0
 
6 posts
Join Date:Joined: Jan 2013
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?
4th January 2013, 10:59 PM   |  #1184  
lupp0l0's Avatar
Member
Thanks Meter: 16
 
81 posts
Join Date:Joined: Aug 2010
More
Quote:
Originally Posted by Proz0r

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
4th January 2013, 11:03 PM   |  #1185  
Senior Member
OKC
Thanks Meter: 79
 
457 posts
Join Date:Joined: Oct 2012
More
Quote:
Originally Posted by Proz0r

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?
4th January 2013, 11:03 PM   |  #1186  
OmegaBlaze's Avatar
Senior Member
Thanks Meter: 266
 
998 posts
Join Date:Joined: Dec 2009
Quote:
Originally Posted by brianoh

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?

Use the app instead of the zip.. There is also a zip to uninstall it somewhere around here.
4th January 2013, 11:07 PM   |  #1187  
OP Senior Member
Flag Montreal
Thanks Meter: 2,966
 
235 posts
Join Date:Joined: Jul 2008
More
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.
The Following 24 Users Say Thank You to lambgx02 For This Useful Post: [ View ]
4th January 2013, 11:09 PM   |  #1188  
zeppelinrox's Avatar
Senior Member
Flag IN THE FREAKIN' OP
Thanks Meter: 21,430
 
9,314 posts
Join Date:Joined: Dec 2010
Donate to Me
More
Quote:
Originally Posted by Proz0r

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
Quote:
Originally Posted by goodtimes50

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
Last edited by zeppelinrox; 4th January 2013 at 11:14 PM.
4th January 2013, 11:10 PM   |  #1189  
emd2009's Avatar
Senior Member
Thanks Meter: 63
 
639 posts
Join Date:Joined: Jun 2007
Donate to Me
More
Quote:
Originally Posted by Proz0r

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
The Following User Says Thank You to emd2009 For This Useful Post: [ View ]
4th January 2013, 11:10 PM   |  #1190  
LeoPosas's Avatar
Recognized Contributor
Flag SPS
Thanks Meter: 3,707
 
1,873 posts
Join Date:Joined: Dec 2011
Donate to Me
More
Quote:
Originally Posted by lambgx02

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?

Post Reply Subscribe to Thread

Tags
entropy, mbq was here, performance
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes