Because most xbian users won't be using a keyboard or usb mouse, the /dev/random entropy pool can become very shallow very quickly. This is used by a lot of things, mainly crypto related, but also a lot of network management related to packet transmission timing.
This can be fixed really easily, by installing a low weight extra system service that gathers extra entropy data from unpredictable system events.
Terminal
sudo apt-get install haveged
And the entropy pool will be kept full with more entropy gathering.
What is the exact advantage of this?
Terminal
The entropy pool size in Linux is viewable through the file /proc/sys/kernel/random/entropy_avail and should generally be at least 2000 bits (out of a maximum of 4096). Entropy changes frequently.
As i can read entropy (/dev/random & /dev/urandom) is used for various applications that use encryption like obvious applications like GPG keys or SSL, but also proper encrypted WLAN connections (and thereby speed). I tested this tools and it's a little but nifty program, not using many resources.
Anything that needs randomness and takes it from the /dev/random entropy pool will block if there's not enough bits to meet their request. And there's a few things that need randomness, including parts of the networking system, that specifically use /dev/random to ensure they're always using the entropy pool. Some things will be okay with resorting to /dev/urandom but that means the kernel has to run cpu bound pseudo-random functions instead when it runs out of data in the entropy pool. Running havege keeps topping up the entropy pool, so the pseudo-random functions rarely if ever get touched, and functions that use /dev/random will rarely if ever block.
Future versions of Linux may include the havege methods, but for now it's mainly gathering unpredictable data from device drivers which will be quite low on the RasbPi.
It's even better if you simply replace urandom/random with frandom/erandom.
I successfully integrated Fast Random (
http://www.billauer.co.il/frandom.html ) into my Android kernel (and the masses followed suit) then another user setup haveged to feed from this, using this method the Android UI remains smooth at all times.
This same method can be used on the Pi to increase the UI responsiveness of XBMC.
frandom appears to require installing a kernel mod and a lightweight management daemon, so I'm not sure if that's any gain over using a lightweight management daemon to refill the entropy pool.
(20th Apr, 2013 10:07 PM)JayBlanc Wrote: [ -> ]frandom appears to require installing a kernel mod and a lightweight management daemon, so I'm not sure if that's any gain over using a lightweight management daemon to refill the entropy pool.
It does require a kernel module. The gain is it's 10x faster than urandom at generation.
You can read more about the Android implementation here (
http://forum.xda-developers.com/showthread.php?t=2113150
[MOD] CrossBreeder -3.15.13-Entropy Lag Reduce/DNS Speedup/Tether boost/Clean Adblock )
Here is a little frandom vs urandom test (frandom is about 10x faster):
For a proper discussion:
https://github.com/xbianonpi/xbian/commit/cafa78a7a2097df03a57c866937d0596fc469eec
And benchmarks on my XBian install:
Terminal
root@pi:~# time head -c 20m /dev/frandom > /dev/null
real 0m0.795s
user 0m0.020s
sys 0m0.770s
root@pi:~# time head -c 20m /dev/urandom > /dev/null
real 0m13.936s
user 0m0.010s
sys 0m13.790s
root@pi:~# time head -c 20m /dev/erandom > /dev/null
real 0m0.783s
user 0m0.020s
sys 0m0.760s
root@pi:~# time head -c 20m /dev/random > /dev/null
real 0m56.068s
user 0m0.400s
sys 0m50.690s
(21st Apr, 2013 12:11 AM)f1vefour Wrote: [ -> ]It does require a kernel module. The gain is it's 10x faster than urandom at generation.
Only when the entropy pool is shallow, otherwise /dev/urandom is just as fast as an mmap. And the network drivers don't use pseudo random sources anyway, so there's no performance gain on wlan.
Oh well, when there are no downsides and possibly gains, then why not.
The downside is inserting an extra kernel mod and all that implies, and trusting that the frandom pseudo randomness is just as good as urandom. Additionally, /dev/frandom isn't a drop in replacement for /dev/urandom, nothing will actually use it without being rewritten to be aware of it.
The extra kernel module is already there and lightweight. The frandom output has been tested and proven ok.
Just in case you missed my edit above, /dev/frandom won't actually be used by anything in the current Xbian. So unless you remove /dev/urandom and put in a symlink to /dev/frandom, there's no benefit at all anyway. And then nothing can access the original urandom.
I made an init script to add those symlinks.
(21st Apr, 2013 01:44 AM)CurlyMo Wrote: [ -> ]The extra kernel module is already there and lightweight. The frandom output has been tested and proven ok.
You rock brother.
(21st Apr, 2013 01:37 AM)JayBlanc Wrote: [ -> ]The downside is inserting an extra kernel mod and all that implies, and trusting that the frandom pseudo randomness is just as good as urandom. Additionally, /dev/frandom isn't a drop in replacement for /dev/urandom, nothing will actually use it without being rewritten to be aware of it.
Frandom is a suitable replacement for urandom, yes symlinks must be made. You symlink frandom/erandom to urandom/random.