If a hardware RNG (random number generator) is present, rng-tools can take advantage of this.  rng-tools is usually available with most Linux distributions, although not typically installed by default.

For the A2000, VIA PadLock RNG is present on the VIA C7-D processor.  (For other VIA/Centaur Technology CPUs, use “cat /proc/cpuinfo | grep rng” to verify it’s present.) Be sure to use modprobe via-rng to load the kernel module (or use lsmod | grep rng to check if it’s already loaded).

The daemon process rngd runs in the background and feeds data to the entropy sink (e.g., /dev/random) from the entropy source (e.g., /dev/hwrng). The configuration file is in /etc/defaults/rng-tools on Debian and Ubuntu. Although the default file indicates to use RNGOPTIONS="--hrng=viapadlock", doing so causes an error on my A2000 of “Could not detect a set of functional, identical VIA PadLock RNGs on every CPU.” (Using --hrng=via also doesn’t work, and I think it’s an obsolete option now.) Hence, I use RNGDOPTIONS="--hrng=viakernel --fill-watermark=90% --feed-interval=1 --rng-quality=high" with HRNGDEVICE=/dev/hwrng. There are other parameters that can be set for rngd. Once the daemon is running, /dev/random will be able to be used for random data (not as fast as /dev/urandom, of course, but still pretty good). This can be used in Apache‘s SSL mod or other programs that may rely on a good source of entropy.

As a bit of digression, if an ANSYS analysis requires creating real random data (e.g., performing a statistical analysis), consider using the RANDSEED macro. ANSYS doesn’t use a true random number generator, and it doesn’t use /dev/random or /dev/urandom. If an APDL script is re-run, the same ‘random’ numbers will be generated, but the use of the RANDSEED macro prevents this from occurring. Of course, this implies that one’s results will slightly change between runs.