假设我有一个需要RNG的程序。
如果我要执行任意操作并检查执行上述操作所需的∆t，则可以从中生成随机数
例如：
double start = device.time();
for(int i=0;i<100;i++);//assume compiler doesn't optimize this away
double end = device.time();
double dt = end-start;
基于设备上的许多变量，例如电池电量，晶体管寿命，室温，正在运行的其他进程等，dt或多或少是随机的
现在，假设我不断生成dt并在进行时将它们相乘数百次，数千次，数百万次，最终我得到的随机数基于或多或少随机的值由硬件性能基准测试计算得出。
[每当我将这些dt乘在一起时，可能的输出呈指数增长，因此，即使每个[dt]的值都是在相似范围内。
然后出现一个想法，如果您有一个非常一致的设备，则您可能将dt始终保持在0.000000011, 0.000000012, 0.000000013, 0.000000014范围内，那么无论我迭代和乘以多少次，最终输出数都将是0.000000011^a * 0.000000012^b * 0.000000013^c * 0.000000014^d形式的数字，可能很容易破解。
但是我转向散列，假设不是将每个dt乘以而是将其以字符串形式连接到先前的值并对其进行散列，因此每次我基于硬件性能的随机环境值生成新的dt时，我都会进行散列。然后最后，我将哈希消化为所需的任何形式，现在最终的输出数字无法以一般的代数形式编写。
以这种形式生成的数字在密码上是否安全？
如果您获取足够的样本，并使用足够少的低时差，那么异步中断的时间可能最终会累加有用的熵。
大多数OS内核将从它们自己的中断处理程序中的计时中收集熵，作为/dev/urandom源的一部分，但是如果您真的想自己滚动而不是向OS询问随机性，那么您是否很可能小心您的混音功能。例如看一下Linux内核用于将新数据混合到其熵池中的用途。它必须避免被在给定系统上实际上不是随机的源“破坏”。
除了中断，短时间的性能几乎是确定性的，CPU频率变化被量化为不多的不同频率。
基于设备上的许多变量，例如...
电池电量：可能是一种2状态效果，例如在不使用交流电源和/或电池电量不足时限制最大涡轮增压。
晶体管年龄：否。如果老化的晶体管使用更多的功率，则最多只是间接影响，从而导致CPU运行温度更高，并且更快退出最大Turbo。我不确定是否会产生重大影响。
室温：再次，只能尽快降低最大时钟速度。除非您为此浪费了几秒钟的CPU时间，否则即使在轻巧的笔记本电脑上也不会产生任何影响。台式机通常具有足够的散热能力，以无限期地在单个内核上维持最大涡轮增压，特别是对于简单的标量代码而言。 （SIMD FMA会产生更多热量。）
正在运行其他进程：是的，恰好在您的定时间隔内出现的异步中断将是随机性的主要来源。
影响时钟速度的大多数因素只会在所有时间均匀地扩展，在样本之间相关，而不是更多的熵。时钟频率不会经常改变。在为基准循环加速至全速后，期望它在几秒钟内保持恒定。