All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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.