Back when pollinate was first introduced with 14.04 Trusty Tahr, it greatly helped to mitigate the lack of entropy that was stalling boots of virtual machines and cloud guests in particular. But the world has changed - while it clearly helped in the past, getting entropy became easier over time and I wanted to reconsider the use of pollinate going forward.
Entropy isn’t what it used to be - nor how the system generates randomness
The hypothesis to test was simple: an older kernel on an older chip without virtio-rng should benefit most from pollinate, and every improvement since then should take away some of that benefit.
To plan measurements effectively, we must hypothesize which variables will most likely influence the outcome
Hardware instructions to get randomness
Timeline of x86 hardware changes to randomness:
- 2012 Intel introduced
RDRAND - 2015 Intel introduced
RDSEEDand AMD introduced bothRDSEEDandRDRAND
I therefore used systems from different generations and manufacturers, and as you’d expect, they generally get faster and introduce rng related instructions.
The chips I tested:
- Xeon-X3430 from 2009 no rd instructions
- Xeon-E52620v3 from 2014 only
RDRAND - EPYC-7742 from 2019 with
RDRANDandRDSEED - EPYC-7502 from 2019 with
RDRANDandRDSEED - Xeon-8362 from 2021 with
RDRANDandRDSEED
Newer chips would only strengthen the conclusion, so I intentionally skipped them, and competition for them in the test infrastructure was fierce anyway.
Kernel changes to get randomness
Timeline of high profile kernel changes to randomness:
- 2018 - v4.19 - Use chip instructions to get randomness via
CONFIG_RANDOM_TRUST_CPU - 2022 - v5.18 - Elimination of the Blocking Pool & Unification of
/dev/random - 2022 - v5.18 - Replacing
SHA-1withBLAKE2sfor Entropy Extraction - 2024 - v6.11 -
Getrandom()speedup via vDSO
Therefore I compared Ubuntu LTS Releases before and after the bigger set of these changes:
- 2022 - Jammy with kernel v5.15
- 2026 - Resolute with kernel v7.0
Virtualization features to get randomness
Entropy usually is easier to get when physical hardware is involved, therefore in virtual environments it could more likely run out. The feature of virtio-rng, through which a host can provide entropy, is available for quite some time but needed more setup than the pure availability in kernel and hardware. One could not rely on it being generally available when pollinate was added back then in 2014, but in the meantime most common management stacks on top configure a virto-rng device by default.
Common stacks introduced virtio-rng by default over time:
- 2017 - virt-manager 1.41
- 2020 - openstack 21.0.0
- 2020 - LXD VM mode had it from day one
Even though virtio-rng is the default everywhere now, I wanted to understand the potential impact of virtio-rng being available or not. To do so, I compared all of the above with and without virtio-rng being made available to the guest.
I didn’t want to go back more than a decade, but instead I decided to compare recent and older releases from this decade. The assumption was that an older Ubuntu release on an old chip might benefit more from pollinate, but with every improvement in the kernel and in hardware this benefit diminishes when comparing it to a modern release on a chip from this decade.
3 2 1 Measure …
The question to solve was whether there could be any future scenario that would suggest keeping pollinate pre-installed by default, or whether it became obsolete should no more be default installed and active.
The benchmark runs to verify this were not very advanced, but did cover the basics of benchmarking, for example:
- Using a clean image
- Alternating A/B tests
- Disabling all kinds of background load that the systems would otherwise spike on, interfering with the measurements.
- Iterating significantly, detecting and filtering statistical outliers via the interquartile range which gladly didn’t need to remove much
- Tracking mean, averages and standard deviation to be aware of potential noise
- Constant VM sizing that even the old bare metal machines could handle without trouble, but that could easily fit the booted minimal VM image without stress. 2 vCPUs and 2GiB fits this nicely (sniff tests with other sizes showed no significant difference)
- To ensure something even needs entropy each time, the necessity to generate SSH keys was re-triggered, back then that was the most common entropy sink stalling first boot
Note: the comparison with and without virtio-rng turned out to be very uninteresting in this scenario: no effect worth a graph on its own or adding another dimension to each graph.
Very old hardware was a big outlier
It turns out, some things indeed get better with time:
The Xeon-X3430 machine of 2009 is 4-5 times slower than the others. It has the slowest boot, the highest noise in measurements and the most consumed CPU cycles of all. In fact, it was so slow that I could only take a reduced amount of measurements before the max timeout got me (which further increased relative noise). This system skews and puts so much noise into the results that I’ll leave it out for the rest of the graphs after this one. Its results were not falsifying the rest of the statements, but making them hard to be seen by not returning anything to rely on. And anyone running on chips of 2009 like me in this test is probably wasting energy by being inefficient and not too concerned about sub second boot speed, since it is orders of magnitude higher than anything more recent 
This can also be seen at the cpu time it needs to run pollinate (which is another metric I gathered), all the others are in 0.13-0.2s and this one is at about 0.45s of a (much slower) cpu.
Things get better
Off-(the RNG)-topic: while speaking about things getting better: I’m happy to see in this setup that we made resolute userspace boot time faster when compared to Jammy, no matter which hardware combination I look at.
No Impact in former releases
With the noisy outlier on the very old machine set aside, the real question remained — does pollinate still help? Let us look at what I found to get a clear answer.
When we look at the 22.04 Jammy or 24.04 Noble results we can see there already wasn’t too much difference between running with pollinate or without. Pollinate here already had diminishing returns. With those releases it started to be a no-op in most cases, it even appears as minimally stalling. But the results are insignificant and were effectively well within the noise range, so it didn’t show much difference and could cover some very old hardware and use cases. It does not hurt and there could be edge cases that still benefit from running with pollinate.
Resolute is the one starting to show significant differences
But the differences get bigger with the newer release: When we look at 26.04 resolute a new pattern starts to show. Pollinate now actually slows down boot speed - by more than the noise and standard deviation could explain. And we should keep in mind that while doing so, it is also spending some CPU cycles, not much but any effort if not contributing is wasted.
But is that also true on very old hardware?
I also measured the very old X3430 CPU in all those cases, and while it was so slow that one could barely see the other results when presented in the same chart, its results still show the same effect. But while slower and more noisy, the results still show that the lack of hardware instructions like on x86 RDRAND / RDSEED does not suddenly jeopardize everything we see in all the other results. I think we should thank the kernel developers for all the improvements. And for this benchmarking campaign it means we do not need to chase down the availability and timeline of instructions like MRS x0, RNDR (arm64), DARN (ppc64el), Zkr (riscv64) across architectures.
Conclusion
My hunch that it was about time to revisit pollinate turned out right. I was able to prove that it became less useful over time until in very recent releases it started to become counterproductive. In modern setups, pollinate slows boot time by about a third of a second, while spending roughly a fifth of a second of a CPU to do so. I was further able to show that this even applies to systems that do not have the related hardware instructions.
Usually, I call you to action at this stage of a post. But this one is not about any single admin tuning their box - it is a decision for all of us in Ubuntu. Pollinate ships on every Ubuntu by default, which means every boot on the most recent release pays a small tax for something that no longer helps. Removing it is the kind of change that quietly benefits the whole ecosystem at once.
Due to that I’d say:
“to speed you up we remove what sped you up!”
And to do so I guess I’ll get ready to discuss seed changes into ubuntu-meta package changes that would change the daily images…
I filed bug 2158262 to track the delivery of this.
And if you miss the extra entropy, I have some alternative source of entropy from my manager-makes-decisions set:
P.S. But you may want …
a) more action: I wish I’d have just found the time to do this earlier, but yes in addition to the change in the next Ubuntu release 26.10 stonking I’ll discuss removing pollinate from the resolute default images as well.
b) less action: This does not mean you can’t use pollinate. If you have very old hardware and a use case that will benefit - no problem, it was not removed from the archive - you can add it to your custom images if you like (as you need it on first boot).