Needs asking the jitter dev because I saw something about this module not having an API one can directly query for random numbers. So it may be working just at a level we can;t detect.
Fair enough. We need to be 100% sure so I will ask.
Got this from a technical writeup not something I made up 
For best accuracy I’d opt for the second sentence.
https://pthree.org/2016/05/24/cpu-jitter-entropy-for-the-linux-kernel/
As mentioned in the list, unfortunately, loading the kernel doesn’t automatically top-off the entropy estimate of the internal state of the CSPRNG (/proc/sys/kernel/random/entropy_avail). As such, /dev/random will still block when the estimate is low or exhausted. So you’ll still need to run a userspace daemon to prevent this behavior. The author has also shipped a clean, light userspace daemon that just reads the data provided by the jitterentropy_rng.ko kernel module, and uses ioctl(2) to increase the estimate. The jitterentropy_rng.ko module provides about 10 KBps of random data.
Again, this isn’t anything that something like haveged(8) doesn’t already have access to. However, by taking advantage of a loaded kernel module, we can ensure that randomness is being collected before the CSPRNG is initialized. So, when CSPRNG initialization happens, we can ensure that it is properly seeded on first boot, minimizing the likelihood that exact keys will be created on distinct systems. This is something haveged(8) can’t provide, as it runs entirely in userspace.