Snail rate of "entropy creation" not increasing significantly with rng-tools

Question

The rate of "entropy creation" on my system (Linux 4.13.0-38-generic, 16.04.1-Ubuntu, Intel® Celeron(R) CPU G3930 @ 2.90GHz × 2, main disk is SSD) is an impractically slow much less than 1 bit per second.

Note: I judge the rate of entropy creation using this command:

watch -n1 cat /proc/sys/kernel/random/entropy_avail

On the other hand, the underlying Linux CSPRNG is producing data at a good pace of about 187 Mb per second:

$ dd if=/dev/urandom of=/dev/null bs=1M count=1024 iflag=fullblock  
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.74347 s, 187 MB/s

I installed rng-tools. It is working and reading /dev/hwrng as expected:

% systemctl status rng-tools
● rng-tools.service
   Loaded: loaded (/etc/init.d/rng-tools; bad; vendor preset: enabled)
   Active: active (running) since Sat 2018-04-28 13:17:17 PDT; 33s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 15840 ExecStop=/etc/init.d/rng-tools stop (code=exited, status=0/SUCC
  Process: 23876 ExecStart=/etc/init.d/rng-tools start (code=exited, status=0/SU
   CGroup: /system.slice/rng-tools.service
           └─23878 /usr/sbin/rngd -r /dev/hwrng

However, the entropy rate is barely changed, and still is far less than 1 bit per second.

The hardware RNG is presumably creating much more than 1 bit per second. So why does the rate of entropy creation not increase significantly?

Answer 1

I found the answer.

The rnd-tools service invokes the program /usr/sbin/rngd. Looking that up in the Ubuntu documentation it can be seen to have a parameter:

-W n, --fill-watermark=nnn

Once we start doing it, feed entropy to random-device until at least fill-watermark bits of entropy are available in its entropy pool (default: 2048).  Setting this too high will cause rngd to dominate the contents of the entropy pool.  Low values will hurt system performance during entropy starves.  Do not set fill-watermark above the size of the entropy pool (usually 4096 bits).

So my testing of the "entropy creation" rate was only done when the buffer was over half full, and that is why it did not increase.

It was easy to check by using this command to empty the buffer:

dd if=/dev/random of=/dev/null bs=256 count=1 iflag=fullblock

That clears out 2048 bits of entropy and then the buffer is then returned to over half full in a fraction of a second.