This explanation from the article comparing /dev/urandom and /dev/random is priceless admin info:
The kernel RNG produces two user-space output streams. One of these goes to /dev/urandom and also to the kernel itself; the latter is useful because there are uses for random numbers within the kernel. The other output stream goes to /dev/random. The difference between the two is that /dev/random tries to estimate how much entropy is coming into the system, and will throttle its output if there is insufficient entropy. By contrast, the /dev/urandom stream does not throttle output, and if users consume all of the available entropy, the interface degrades to a pure CSPRNG.
via LCE: Don’t play dice with random numbers [LWN.net].
I had no idea that non-Intel processors had boundary restricted byte operations. This certainly could mean general network speedup.
It ultimately turned out that certain device drivers were exposing a problem in the alignment handler. By accessing misaligned IP header fragments, the driver concerned was triggering an alignment exception within an atomic-critical section of kernel code, which was then resulting in the scheduler being called from within the alignment handler. Although the driver was later fixed to improve performance (by using only aligned data), the problem with the alignment handler itself did require fixing to prevent unwanted system crashes.
via The Kernel Column with Jon Masters – Linux Kernel 3.7 | Linux User.