Just the apk will do...if it does not work well, use the zip (not those in the first post)...it will not damage your hardware...and quite impossible to damage your software too......rngd can be removed...
1. Hiw to install this??? Im a bit confused. Just install the apk, right???
2 If itll damage my system, is it just software or can it also damage hardware???
3Is the damage temporary or could it be forever
Is there any proof for how well this works? Or is it all just subjective now? Has anybody tossed in some printk() into the kernel and had it tell each and every time it blocked while waiting for data to spit out at /dev/random? It would be interesting to see some logs like this with and without this hack running to get some real measurable results from different situations.
EDIT:
I added in some printk() as mentioned above and then observed "cat /proc/kmsg" while doing some stuff like switching menus, playing around in google maps, and basically clicking around the places that people said they saw a noticeable speed improvement. I did not observe any logging at all coming from the random_read() from within the kernel. To verify my printk() was working, I ran "cat /dev/random > /dev/null" and my logging does print the jiffies the operation took, and well as if it was blocked. As I didn't see any logging at all besides when purposefully reading from the random file, then it would stand to reason that nothing is reading from /dev/random at all while switching through the menus and playing around in google maps. Unless I'm misunderstanding the topic, the hack wouldn't have had any affect on reducing lagginess when there is nothing reading from that file.
My test phone is a VM-696 using android 2.3.7 and an otherwise stock kernel. Below is the modified function from drivers/char/random.c in the kernel.
./dalvik/tests/071-dexfile/src/Main.java: * /dev/random never hits EOF, so we're sure that we'll still
./dalvik/tests/071-dexfile/src/Main.java: ProcessBuilder pb = new ProcessBuilder("cat", "/dev/random");
./frameworks/base/services/java/com/android/server/EntropyService.java: * {@code /dev/random} may be in a fairly predictable state. Applications which
./frameworks/base/services/java/com/android/server/EntropyService.java: * depend strongly on randomness may find {@code /dev/random} or
./libcore/luni/src/main/java/org/apache/harmony/security/provider/crypto/SHA1_Data.java: // BEGIN android-changed: /dev/random seems to be empty on Android
./libcore/luni/src/main/java/org/apache/harmony/security/provider/crypto/SHA1_Data.java: static final String DEVICE_NAMES[] = { "/dev/urandom" /*, "/dev/random" */ };
./libcore/luni/src/main/java/org/apache/harmony/security/provider/crypto/RandomBitsSupplier.java: * "/dev/random" depends on which one is available; if both the first is used. <BR>
./libcore/luni/src/main/java/org/apache/harmony/security/provider/crypto/RandomBitsSupplier.java: // the below case should not occur because /dev/random or /dev/urandom is a special file
./bionic/libc/bionic/dlmalloc.c: Causes malloc to use /dev/random to initialize secure magic seed for
./prebuilt/linux-x86/toolchain/arm-linux-androideabi-4.4.x/arm-linux-androideabi/include/c++/4.4.3/arm-linux-androideabi/thumb/bits/c++config.h:/* Define if /dev/random and /dev/urandom are available for the random_device
./prebuilt/linux-x86/toolchain/arm-linux-androideabi-4.4.x/arm-linux-androideabi/include/c++/4.4.3/arm-linux-androideabi/bits/c++config.h:/* Define if /dev/random and /dev/urandom are available for the random_device
./prebuilt/linux-x86/toolchain/arm-linux-androideabi-4.4.x/arm-linux-androideabi/include/c++/4.4.3/arm-linux-androideabi/armv7-a/thumb/bits/c++config.h:/* Define if /dev/random and /dev/urandom are available for the random_device
./prebuilt/linux-x86/toolchain/arm-linux-androideabi-4.4.x/arm-linux-androideabi/include/c++/4.4.3/arm-linux-androideabi/armv7-a/bits/c++config.h:/* Define if /dev/random and /dev/urandom are available for the random_device
./prebuilt/linux-x86/toolchain/i686-linux-glibc2.7-4.4.3/i686-linux/include/c++/4.4.3/i686-linux/bits/c++config.h:/* Define if /dev/random and /dev/urandom are available for the random_device
./prebuilt/linux-x86/toolchain/i686-linux-glibc2.7-4.4.3/sysroot/usr/include/linux/jbd.h:#define JFS_MAGIC_NUMBER 0xc03b3998U /* The first 4 bytes of /dev/random! */
./prebuilt/darwin-x86/toolchain/arm-linux-androideabi-4.4.x/arm-linux-androideabi/include/c++/4.4.3/arm-linux-androideabi/thumb/bits/c++config.h:/* Define if /dev/random and /dev/urandom are available for the random_device
./prebuilt/darwin-x86/toolchain/arm-linux-androideabi-4.4.x/arm-linux-androideabi/include/c++/4.4.3/arm-linux-androideabi/bits/c++config.h:/* Define if /dev/random and /dev/urandom are available for the random_device
./prebuilt/darwin-x86/toolchain/arm-linux-androideabi-4.4.x/arm-linux-androideabi/include/c++/4.4.3/arm-linux-androideabi/armv7-a/thumb/bits/c++config.h:/* Define if /dev/random and /dev/urandom are available for the random_device
./prebuilt/darwin-x86/toolchain/arm-linux-androideabi-4.4.x/arm-linux-androideabi/include/c++/4.4.3/arm-linux-androideabi/armv7-a/bits/c++config.h:/* Define if /dev/random and /dev/urandom are available for the random_device
./external/dropbear/libtommath/mtest/mtest.c: rng = fopen("/dev/random", "rb");
./external/dropbear/options.h:/* We'll use /dev/urandom by default, since /dev/random is too much hassle.
./external/dropbear/libtomcrypt/src/prngs/rng_get_bytes.c:/* on *NIX read /dev/random */
./external/dropbear/libtomcrypt/src/prngs/rng_get_bytes.c: f = fopen("/dev/random", "rb");
./external/libffi/src/dlmalloc.c: Causes malloc to use /dev/random to initialize secure magic seed for
./external/openssl/crypto/rand/rand_unix.c: * have this. Use /dev/urandom if you can as /dev/random may block
./external/openssl/e_os.h:#define DEVRANDOM "/dev/urandom","/dev/random","/dev/srandom"
./external/e2fsprogs/lib/uuid/gen_uuid.c: fd = open("/dev/random", O_RDONLY | O_NONBLOCK);
./external/e2fsprogs/lib/uuid/gen_uuid.c: * randomness if /dev/random/urandom is out to lunch.
./external/e2fsprogs/lib/ext2fs/kernel-jbd.h:#define JFS_MAGIC_NUMBER 0xc03b3998U /* The first 4 bytes of /dev/random! */
./external/e2fsprogs/lib/ext2fs/jfs_dat.h:#define JFS_MAGIC_NUMBER 0xc03b3998U /* The first 4 bytes of /dev/random! */
./external/sqlite/dist/sqlite3.c:** was obtained from /dev/random. It is used only as a sanity check.
./external/busybox/e2fsprogs/old_e2fsprogs/uuid/gen_uuid.c: fd = open("/dev/random", O_RDONLY | O_NONBLOCK);
./external/busybox/e2fsprogs/old_e2fsprogs/uuid/gen_uuid.c: * randomness if /dev/random/urandom is out to lunch.
./external/busybox/e2fsprogs/old_e2fsprogs/ext2fs/kernel-jbd.h:#define JFS_MAGIC_NUMBER 0xc03b3998U /* The first 4 bytes of /dev/random! */
./external/busybox/e2fsprogs/old_e2fsprogs/ext2fs/jfs_dat.h:#define JFS_MAGIC_NUMBER 0xc03b3998U /* The first 4 bytes of /dev/random! */
./external/qemu/distrib/sdl-1.2.12/src/stdlib/SDL_malloc.c: Causes malloc to use /dev/random to initialize secure magic seed for
./external/ppp/pppd/plugins/radius/sendserver.c: we use /dev/urandom here, as /dev/random might block and we don't
./external/kernel-headers/original/linux/jbd.h:#define JFS_MAGIC_NUMBER 0xc03b3998U /* The first 4 bytes of /dev/random! */
grep -r --include="*.cpp" --include="*.c" --include="*.java" --include="*.h" --include="*.hpp" --exclude="out" --exclude="prebuilt" "/dev/random" .
I'm starting to have doubts about seeder making things faster....
When I just flashed it it seemed that way. When I load messages after using a few other apps it still takes a bit of time.... It only goes without lag when it was very recently used.
send from HTC Sensation XE on ViperS 1.5.2 ROM 32gb class10 using Tapatalk
-- Snip --
As you can see, all the occurences are either in comments (with /dev/urandom actually used in code) or in rarely used tools (uuid_gen, dropbear, e2fsprogs) or in tests (that aren't part of the ROM).
Maybe the whole secret of this mod is that it generates CPU usage, which keeps CPU frequency at high level, removing the delays needed to scale up the CPU from low frequency (with bad cpufreq governor and/or not well tuned governor parameters), which might be perceived as what you call a "lag". Could you check how much CPU the seeder daemon needs, for example by using top command? You should also be able to monitor cpufreq statistics through /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state file.
You're right; the man page is slightly misleading and I might've misunderstood.It is not true that /dev/urandom is unsafe. It is safe for most of use cases, even for cryptography. It's unsuitable for use cases requiring high level of randomness like key generation or some scientific calculations (e.g. monte carlo-based simulations).
It's a placebo effect. I told you to test it's effectiveness you have to turn it on, do your checks, than turn it off and do the same things again within the same boot instance. You'll probably notice no difference, like me.
the apk doesn`t work , it switches off after i exit the app neatrom + siyah , and the zip cannot be installed
Bad testing method. If anything, test with it off, THEN test with it on. Remember, this increases the available data in /dev/random. Once it's increased, you would have to deplete the pool again completely before you could test performance without the mod's effect. You're seeing no difference because you're not depleting the pool before you run your second set of tests.It's a placebo effect. I told you to test it's effectiveness you have to turn it on, do your checks, than turn it off and do the same things again within the same boot instance. You'll probably notice no difference, like me.
Sent from my HTC Sensation Z710e using Tapatalk 2
Bad testing method. If anything, test with it off, THEN test with it on. Remember, this increases the available data in /dev/random. Once it's increased, you would have to deplete the pool again completely before you could test performance without the mod's effect. You're seeing no difference because you're not depleting the pool before you run your second set of tests.
busybox sysctl -e -w kernel.random.read_wakeup_threshold=128;
busybox sysctl -e -w kernel.random.write_wakeup_threshold=256;
while :; do cat /proc/sys/kernel/random/entropy_avail; sleep 1;done
busybox sysctl -w kernel.random.read_wakeup_threshold=2048
echo 1366 > /proc/sys/kernel/random/read_wakeup_threshold
busybox sysctl -w kernel.random.read_wakeup_threshold=1366
busybox sysctl -e -w kernel.random.read_wakeup_threshold=1024;
busybox sysctl -e -w kernel.random.write_wakeup_threshold=2048;
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.
[-- awesome finding snipped because @zeppelinrox is too awesome --]
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.
RWUT="$(cat /proc/sys/kernel/random/poolsize)"
RWUT="$((RWUT/3))"
heh it was just dumb luck that the entropy_watch.c file popped up in a search so I just compiled it since I was in the moodHi Zep!
Thanks very much for dropping by. . your entropy_watch binary has been so very helpful for us :thumbup:
Hmmm... it seems I'll be doing 3 tests then... I'll do it later in the afternoon. Do you think 1 hour per test will be enough? I plan on leaving my phone unused, untouched during every test, recharging to at least 80% between tests...
-- Sent from a GT-I8150 running ICS perfectly well. F'U, Sams#!t --
---------- Post added at 01:30 PM ---------- Previous post was at 01:14 PM ----------
For a generic number that adapts to all kernels, use the following:
Afterwards, simply echo $RWUT to the location given by @zeppelinroxCode:RWUT="$(cat /proc/sys/kernel/random/poolsize)" RWUT="$((RWUT/3))"
-- Sent from a GT-I8150 running ICS perfectly well. F'U, Sams#!t --
heh it was just dumb luck that the entropy_watch.c file popped up in a search so I just compiled it since I was in the mood
I actually like running that one liner while loop which can be just thrown in a script, chmod it and there ya go.
Yeah well you'll see immediately that it will behave as expected.
I'd imagine that just leaving it maxed would save battery since by default entropy_avail is continually fluctuating up and down in the 200 - 300 range anyway.
May as well leave it full for free instead of empty at the same price lol
Unfortunately, your grepping doesn't prove a thing...
The name /dev/random might be placed into a variable once, and from that point on referred to using the variable's name, e.g. in SHA1_data.java
Or, the /dev/random device might be opened once but read many times, e.g. rng_get_bytes.c
And it's highly likely that /dev/random is opened within a function, and that function gets called a lot of times from other code. Without code audit, you won't see these 'indirect' usage of /dev/random.
Also, the source's comments sometimes refer to '/dev/random', but no code is emitted that explicitly use the string '/dev/random'; I'm guessing that in those instances, (one of) the method used is by directly accessing the device node number.
This makes more sense. I'm going to do that exactly.
You're right; the man page is slightly misleading and I might've misunderstood.
-- Sent from a GT-I8150 running ICS perfectly well. F'U, Sams#!t --
---------- Post added at 09:03 AM ---------- Previous post was at 08:57 AM ----------
But if rngd is just 'placebo effect', what has been consuming my entropy (as shown by entropy_watch)?
That said, I am interested in your entropy pool... could you run entropy_watch and post me the first 10-20 lines?
-- Sent from a GT-I8150 running ICS perfectly well. F'U, Sams#!t --
lsof | grep "/dev/random"
Actually, that sounds like the purpose of read_wakeup_threshold.So, if the entropy pool empties, apps will still be blocked for some time while waiting the kernel to refill the pool.
If apps 'behave' by never requesting a huge chunk of entropy, setting RWUT should be enough. But in my phone, something's been gobbling up entropy with a serving size of > 3000 bits, bringing entropy_avail to as low as 98 bits. If the rate of entropy generation is not fast enough, the next app(s) will still be blocked.
Haven't actually tested, though. Will do as soon as I get back to office
Unfortunately, lsof produces a snapshot in time only. You have to put it in a loop to capture anything.I actually did more code analysis than just this single grep, but results were identical.
You can as well check if /dev/random is used by running
Code:lsof | grep "/dev/random"
On my phone (with latest CyanogenMod 7) this command does not return any output, which means that /dev/random is not opened by any process.
Well, they're still humans.Btw2. Google engineers would have to be idiots (which I believe is NOT the case) to use /dev/random in a way that degrades system performance. Android is not perfect, but it doesn't contain such elementary mistakes.
su
seeder
su
cd /sdcard/install
sh install.sh
su
cd /sdcard
sh uninstall.sh
watch -n 1 cat /proc/sys/kernel/random/entropy_avail
pgrep rngd
su
seeder
su
cd /sdcard/install
sh install.sh
su
cd /sdcard
sh uninstall.sh
busybox sysctl -e -w kernel.random.read_wakeup_threshold=128;
busybox sysctl -e -w kernel.random.write_wakeup_threshold=256;
while :; do cat /proc/sys/kernel/random/entropy_avail; sleep 1;done
busybox sysctl -w kernel.random.read_wakeup_threshold=2048
echo 1366 > /proc/sys/kernel/random/read_wakeup_threshold
busybox sysctl -w kernel.random.read_wakeup_threshold=1366
busybox sysctl -e -w kernel.random.read_wakeup_threshold=1024;
busybox sysctl -e -w kernel.random.write_wakeup_threshold=2048;
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'!