FORUMS

What Do You Think About Fingerprint Scanners?

More and more phones are featuring fingerprint scanners, and with many promising … more

What’s Next for Samsung and Its Flagships?

If we were to say that the Galaxy S6 was a leap of faith made by Samsung, we … more

The Ultimate Showcase of dBrand Skins

In the search for ways to protect, accessorize, and personalize; a user has many options. One … more

Huawei’s Rapid Rise to Third Place in the Smartphone Race

Huawei has quickly grown to become one of the world’s biggest … more

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

235 posts
Thanks Meter: 2,997
 
By lambgx02, Senior Member on 12th November 2012, 07:18 AM
Post Reply Subscribe to Thread Email Thread
4th January 2013, 09:50 PM |#1181  
orangekid's Avatar
Senior Moderator / Moderator Committee / Bacon Enthusiast
Thanks Meter: 4,620
 
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, 09:57 PM |#1182  
OmegaBlaze's Avatar
Senior Member
Thanks Meter: 427
 
More
As promised!
The Following 4 Users Say Thank You to OmegaBlaze For This Useful Post: [ View ]
4th January 2013, 09:58 PM |#1183  
Junior Member
Thanks Meter: 0
 
More
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, 09:59 PM |#1184  
lupp0l0's Avatar
Member
Thanks Meter: 17
 
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, 10:03 PM |#1185  
Senior Member
OKC
Thanks Meter: 86
 
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, 10:03 PM |#1186  
OmegaBlaze's Avatar
Senior Member
Thanks Meter: 427
 
More
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, 10:07 PM |#1187  
OP Senior Member
Flag Montreal
Thanks Meter: 2,997
 
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, 10:09 PM |#1188  
zeppelinrox's Avatar
Senior Member
Flag IN THE FREAKIN' OP
Thanks Meter: 21,643
 
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 10:14 PM.
4th January 2013, 10:10 PM |#1189  
emd2009's Avatar
Senior Member
Thanks Meter: 91
 
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, 10:10 PM |#1190  
LeoPosas's Avatar
Recognized Contributor
Flag SPS
Thanks Meter: 3,835
 
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?
4th January 2013, 10:12 PM |#1191  
Junior Member
Thanks Meter: 0
 
More
Quote:
Originally Posted by OmegaBlaze

Use the app instead of the zip.. There is also a zip to uninstall it somewhere around here.

Yes, in hindsight I should have done that. I flashed to v6 as there is a v6 uninstall zip that you can flash. Is there a way to see if the zip is in fact inactive after?

Read More
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