Forum

Full Version: Playing with /dev/random and available entropy
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
After reading a thread on XDA about symlinking /dev/random to /dev/urandom and playing with the kernels read/write_wake_threshold values on Android devices I thought I'd try it on the Pi. There's a debate going in the XDA thread and on ASOP that it's just a placebo but hundreds of users have noticed a significant performance difference on their phones and Android kernel maintainers have begun to integrate the changes.

/dev/random generates entropy from numerous sources in the real-wrodl environment, e.g. keyboard strokes, mouse movement, touch screen swipes, and even sound via the microphone. With the Pi none of this happens as none of these devices are connected (for me anyway) so entropy generation is a little limited. You can check your current level with
Code:
cat /proc/sys/kernel/random/entropy_avail
- it will probably be around 128 - 192. The issue with /dev/random is that its blocking, so if you request 256 bits of entropy but the kernel only has 150 then the kernel will block your code until the extra bits are available, which in turn slows your application down.

/dev/urandom is non-blocking so it won't hold your application, it will just keep generating entropy and thus faster responding apps.

NOTE: /dev/urandom is "less secure" then /dev/random (Google it for an explanation) - this doesn't bother me.

Using XBMC I've noticed a slight speed difference in just browsing through the menus, e.g. the "Settings" screen loads faster. fgrep-ing my way through the source code /dev/random is only used a few times within the XBMC code, one of ffmpegs libraries and libenca (used for text encoding) so it shouldn't make a difference. I know its used throughout the kernel and many other applications/libraries (e.g Couch Potato), SMB, anything to do with SSL, SSH, etc.

Anyway long story short here's what I did:
Code:
apt-get install rng-tools
nano /etc/default/rng-tools
set HRNGDEVICE=/dev/urandom
/etc/init.d/rng-tools restart
mv /dev/random /dev/random.orig
ln -s /dev/urandom /dev/random
sysctl -e -w kernel.random.read_wakeup_threshold=1024
sysctl -e -w kernel.random.write_wakeup_threshold=2048

Check your entropy now, it should be at least 3000.

I'd be interested to see if anybody experiences any performance increases after doing this and its not just a placebo? To revert this just stop the rng-tools daemon, restore the /dev/random.org file and set the read/write thresholds back to 64 and 128 respectively.

NOTE: The thresholds will reset on reboot, add them to /etc/sysctl.conf. I could be wrong on some of the information above, it's just what I've read in a few hours! Smile

Cheers.
Let me at first share this with you:
Code:
cat /proc/sys/kernel/random/entropy_avail
3836
Interesting, mine was always hovering around ~140ish - what are you running on your Pi?
Just what you guys are Wink
on mine shows only 137
CurlyMo: already changed your thresholds?

Rikardo: would be interested to see if you notice any performance gain from this Smile
No
is it supposed to survive reboot ?
i did the steps and it showed arround 2700ish than i rebooted and now is back to low 128
As long as you set your thresholds in /etc/sysctl.conf as well
Reference URL's