Some virtio-rng providers are known to ratelimit to rates below what
random(4) expects for 'fast' sources. Because we read all sources
serially, this lowers the overall quality of the pool while driving up
CPU utilization to some extent as we spend more time spinning in
This commit by default times out polling at 2ms. This is based on a
rough estimate of how long this should take with fortuna to avoid
10hz / RANDOM_FORTUNA_NPOOLS(32) calls = ~3ms per call at most to avoid
bringing everyone down; shave off 1ms of 'other overhead' to arrive at
2ms for the poll itself.
If we end up timing out, the next iteration will simply drop the result
on the floor -- we can't quickly know how long it's been sitting in the
now heap-allocated buffer, because it may have been enqueued on the last
read of this source in random_sources_feed().