rand(2), cons(3): clarify /dev/random behaviour
This commit is contained in:
parent
f777743b72
commit
b59aa67922
2 changed files with 4 additions and 11 deletions
|
@ -109,10 +109,6 @@ starting state.
|
|||
.I Truerand
|
||||
returns a random unsigned long read from
|
||||
.BR /dev/random .
|
||||
Due to the nature of
|
||||
.BR /dev/random ,
|
||||
truerand can only return a few hundred bits a
|
||||
second.
|
||||
.PP
|
||||
.I Ntruerand
|
||||
returns a uniform random integer
|
||||
|
|
|
@ -114,13 +114,10 @@ The hostowner also has group permissions for any local devices.
|
|||
.PP
|
||||
Reads from
|
||||
.B random
|
||||
return a stream of random numbers. The numbers are
|
||||
generated by a low priority kernel process that loops
|
||||
incrementing a variable. Each clock tick the variable
|
||||
is sampled and, if it has changed sufficiently, the last
|
||||
few bits are appended to a buffer. This process is inefficient
|
||||
at best producing at most a few hundred bits a second.
|
||||
Therefore,
|
||||
return a stream of random bytes produced by the kernels cryptographic
|
||||
random number generator. The rate at which data can be read depends on
|
||||
the implementation and can vary from hundreds of megabytes to just
|
||||
a few hundred bits a second. Therefore,
|
||||
.B random
|
||||
should be treated as a seed to
|
||||
pseudo-random number generators which can produce a faster
|
||||
|
|
Loading…
Reference in a new issue