🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #12706

Re: random number generator in hardware

#12706
From: Roy Smith
Date: Fri, 14 Nov 1986 03:14
42 lines
2816 bytes
In article <2490@phri.UUCP> I wrote:
> Why don't computers come with hardware random number generators? [...]
> On my Sun-3/50 [it takes] about 22 uSec per random integer.  With white
> noise generators you should be able to do it a lot faster, and get more
> random numbers to boot.

	Let me rephrase that a bit.  As Edward Wang <ucbvax!edward>
rightfully pointed out, 22 uSec to get a random integer is not anything you
should be sweating about.  For most applications, the time to pick random
numbers compared to whatever processing you do with those numbers is pretty
trivial.

	The real reason I want a random number register based on a white
noise generator is to get more random random numbers.  If the reader was
left with the impression that I was mostly concerned about speed, I
apologise.  The misunderstanding is entirely the fault of my sloppy
writing.

	If you need a system call to access this register, you're sure to
lose in the speed department anyway, and lose big.  But do you really need
a system call?  Why not a "read processor register" instruction that's
executable in user mode and lets you read the value of the random register,
time of day clock, CPU type and serial number, etc.

	My diversion into the timing of random(III) was only to show that
there isn't any reason why a read of the random register need be as fast as
a typical CPU register read would be.  If a typical instruction time on
your machine was, say 100nS, it wouldn't make much difference if reading
the random register took 1uS, or even 10 uS, would it?  Starting a 10 uSec
timer each time you read the register and blocking subsequent reads until
the timer expired would be simple, and even if you did as few as 100
instructions between random reads, you would never block.

	So, with my point hopefully made clear this time, I re-ask the
question.  Is there any merit to this, or is it off-the-wall?  Would the
cost of adding the random hardware be justified by the use it would get?
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

"you can't spell deoxyribonucleic without unix!"
Technical Details
Message-ID: <2500@phri.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!cmcl2!phri!roy
References: <317@zuring.mcvax.UUCP> <267@bath63.UUCP> <2490@phri.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!cmcl2!phri!roy
From: roy@phri.UUCP (Roy Smith)
Newsgroups: comp.arch
Subject: Re: random number generator in hardware
Message-ID: <2500@phri.UUCP>
Date: Thu, 13-Nov-86 22:14:54 EST
Article-I.D.: phri.2500
Posted: Thu Nov 13 22:14:54 1986
Date-Received: Fri, 14-Nov-86 02:03:52 EST
References: <317@zuring.mcvax.UUCP> <267@bath63.UUCP> <2490@phri.UUCP>
Reply-To: roy@phri.UUCP (Roy Smith)
Organization: Public Health Research Inst. (NY, NY)
Lines: 42
Summary: speed isn't the issue; better randomness is