From: "H. Peter Anvin" <hpa@zytor.com>
To: Stephan Mueller <smueller@chronox.de>
Cc: "Theodore Ts'o" <tytso@mit.edu>, "Jörn Engel" <joern@logfs.org>,
"Linux Kernel Developers List" <linux-kernel@vger.kernel.org>,
macro@linux-mips.org, ralf@linux-mips.org, dave.taht@gmail.com,
blogic@openwrt.org, andrewmcgr@gmail.com, geert@linux-m68k.org,
tg@mirbsd.de, sandyinchina@gmail.com
Subject: Re: [RFC PATCH 0/5] CPU Jitter RNG
Date: Tue, 04 Feb 2014 13:34:40 -0800 [thread overview]
Message-ID: <52F15CF0.8080209@zytor.com> (raw)
In-Reply-To: <1874855.zG4mP2DzbB@tauon>
On 02/04/2014 12:31 PM, Stephan Mueller wrote:
>>
>> The quantum noise sources there are in a system are generally two
>> independent clocks running against each other. However, independent
>> clocks are rare; instead, most clocks are in fact slaved against each
>> other using PLLs and similar structures. When mixing spread spectrum
>> clocks and non-spread-spectrum clocks that relationship can be very
>> complex, but at least for some designs it is still at its core
>> predictable.
>
> But isn't there an additional clock? The clock used to drive the cache
> and memory bus? When measuring memory accesses timings, larger
> variations in the execution time are evident. This also applies when
> hitting the caches (for L1, the variations are less than for L2 than for
> L3). The variations in access timings would come from the CPU wait
> states and their duration, would it not?
>
Variations doesn't mean quantum unpredictable noise. All the clocks you
are referring to are derived from the same BCLK and thus predictable.
What you have here is a PRNG with a large and obscure state space.
-hpa
next prev parent reply other threads:[~2014-02-04 21:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-04 12:36 [RFC PATCH 0/5] CPU Jitter RNG Stephan Mueller
2014-02-04 12:39 ` [PATCH 1/5] " Stephan Mueller
2014-02-04 12:40 ` [PATCH 2/5] CPU Jitter RNG: Enable compilation Stephan Mueller
2014-02-04 13:39 ` Geert Uytterhoeven
2014-02-04 16:19 ` Stephan Mueller
2014-02-04 16:39 ` Hannes Frederic Sowa
2014-02-04 16:50 ` Hannes Frederic Sowa
2014-02-04 16:53 ` Stephan Mueller
2014-02-04 17:15 ` Hannes Frederic Sowa
2014-02-04 12:40 ` [PATCH 3/5] CPU Jitter RNG: integration with /dev/random Stephan Mueller
2014-02-04 12:41 ` [PATCH 4/5] CPU Jitter RNG: provide status proc files Stephan Mueller
2014-02-04 12:42 ` [PATCH 5/5] CPU Jitter RNG: add read/write sysctls Stephan Mueller
2014-02-04 17:08 ` [RFC PATCH 0/5] CPU Jitter RNG Theodore Ts'o
2014-02-04 19:06 ` H. Peter Anvin
2014-02-04 19:23 ` tytso
2014-02-04 19:39 ` Geert Uytterhoeven
2014-02-04 20:39 ` H. Peter Anvin
2014-02-04 21:46 ` Geert Uytterhoeven
2014-02-04 21:47 ` H. Peter Anvin
2014-02-10 21:07 ` Jörn Engel
2014-02-04 20:31 ` Stephan Mueller
2014-02-04 21:34 ` H. Peter Anvin [this message]
2014-02-04 21:43 ` Geert Uytterhoeven
2014-02-04 20:25 ` Stephan Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52F15CF0.8080209@zytor.com \
--to=hpa@zytor.com \
--cc=andrewmcgr@gmail.com \
--cc=blogic@openwrt.org \
--cc=dave.taht@gmail.com \
--cc=geert@linux-m68k.org \
--cc=joern@logfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=sandyinchina@gmail.com \
--cc=smueller@chronox.de \
--cc=tg@mirbsd.de \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.