5th Jan, 2013, 04:48 AM
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
- 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:
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!
Cheers.
/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/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=2048Check 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!
Cheers.
