Every deterministic machine has one problem it fundamentally can't solve: producing a number nobody can predict. Modern CPUs solve this by cheating — they include a physical entropy source that samples analog chaos and turns it into bits.

Intel's Digital Random Number Generator (DRNG), exposed via RDRAND and RDSEED, is built around a pair of cross-coupled inverters wired into a metastable state. Thermal noise pushes the circuit one way or the other, and a sampler captures which side won. That raw bit stream is biased and correlated, so it goes through a three-stage pipeline:

• Entropy source (ES): the analog noise circuit, producing ~3 Gbps of raw bits.
• Online health tests + conditioner: AES-CBC-MAC compresses the raw stream into full-entropy 256-bit seeds.
• DRBG (deterministic random bit generator): an AES-CTR-based PRNG reseeded frequently from the conditioner, feeding RDRAND.

RDSEED pulls directly from the conditioner output — true entropy, suitable for seeding your own PRNG or generating long-term keys. RDRAND pulls from the DRBG — cryptographically strong but computationally derived. This is why RDSEED can fail (return CF=0) far more often: the entropy pool physically drains faster than you can pull from it.

The performance reality: RDRAND on Skylake takes ~200 cycles and only issues one at a time per core. RDSEED under contention can take thousands of cycles or fail outright. If you're generating a lot of randomness, you use RDSEED once to seed a userspace ChaCha20 or AES-CTR, then generate gigabytes cheaply.

Concrete example: Linux's getrandom() doesn't call RDRAND directly for every request. The kernel's CRNG uses RDSEED (when available) to reseed its internal ChaCha20 pool every few minutes, then serves userspace from that pool. One physical entropy pull → billions of software-generated bytes.

Rule of thumb: If you need N random bytes and N > 32, never loop RDRAND. Pull one 256-bit seed with RDSEED, expand with a stream cipher. You'll get roughly a 100× throughput improvement and won't starve other cores waiting on the same entropy source.

A subtle trap: RDRAND can silently return stale data if you don't check the carry flag. The Linux kernel patched around AMD Ryzen bugs where RDRAND returned all-ones after suspend/resume — always check CF=1 before trusting the result.