On 5/18/23 16:05, Rich Pieri wrote:
I don't know if this is what happened
on Kent's system or not. There are lots of reasons why I/O performance
can change
It is faster compared to a different machine, a few years ago.
The reason I wanted fast random data was to paint a new disk with random
bits before setting up an encrypted disk. The previous machine would
have had:
- slower (32-bit?) CPU and RAM.
- slower USB hardware to disk (I seem to remember ~50MB/s)
- older kernel with completely different random.c
At that point trying to dd from /dev/urandom to an external disk,
/dev/urandom was the bottleneck, a lot slower than the disk. I even
wrote a hacky RNG in Python to speed it up: Encrypt a counter, using a
key from /dev/urandom, rollover the key every few gigabytes or so. (This
RNG approach was not my invention, it is classic, and I used a Python
library to do the encryption, so the stuff in the middle was not that
dangerous a thing for me to program, and not a critical usage if I got
it wrong.)
I conclude that random.c implemented a much slower /dev/urandom than
does the version I have now. But maybe my current CPU is much better at
running this code.
Heck, the Raspberry Pi 4 I tested on today produces urandom data much
faster than the old bandwidth to disk I remember.
-kb, the Kent who is currently running current stable Debian, amd64.
_______________________________________________
Discuss mailing list
[email protected]
http://lists.blu.org/mailman/listinfo/discuss
