schrieb Konstantin Belousov am 12.10.2012 18:48 (localtime): > On Fri, Oct 12, 2012 at 10:50:55AM +0200, Harald Schmalzbauer wrote: >> ... > Try the stable/9 instead. The code was merged in r240950. > There was a bug in the original patch with the similar description. Thanks, it seems to be working with r240950 for RELENG_9_1 (ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/deploy-tools/local-patches/RELENG_9_1/from_9-stable_branch/bull_mountain.patch). dd if=/dev/random bs=1k count=1000 | ent 1000+0 records in 1000+0 records out 1024000 bytes transferred in 0.028026 secs (36537676 bytes/sec) Entropy = 7.999827 bits per byte. Optimum compression would reduce the size of this 1024000 byte file by 0 percent. Chi square distribution for 1024000 samples is 244.91, and randomly would exceed this value 66.40 percent of the times. Arithmetic mean value of data bytes is 127.6039 (127.5 = random). Monte Carlo value for Pi is 3.139277888 (error 0.07 percent). Serial correlation coefficient is -0.001852 (totally uncorrelated = 0.0). I don't know if the requested verbose-boot-log is also of interest with ESXi-Guest, in case I've attached it. I think the man page answers my question how to find out (without verbose_boot) what real rng is used for /dev/random. If sysctl kern.random.sys is present, then it's sw rng, otherwise it's hw-rng. But random(4) needs to be uptdated: The only hardware implementation currently is for the VIA C3 Nehemiah (stepping 3 or greater) CPU. More will be added in the future Also, long time ago we had support for i815 RNG. Back in December 2005, Mark Murray planned to re-implement it... Does anybod know if the chipset RNG was still available in decent hw? Here's the throughput difference for bull mountain (in ESXi 5.1 guest): With options RDRAND_RNG: dd if=/dev/random of=/dev/null bs=1k count=100000 100000+0 records in 100000+0 records out 102400000 bytes transferred in 0.722204 secs (141788199 bytes/sec) Without: dd if=/dev/random of=/dev/null bs=1k count=100000 100000+0 records in 100000+0 records out 102400000 bytes transferred in 1.054229 secs (97132594 bytes/sec) Thanks, -Harry
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:31 UTC