4 ms·

Yeah basically. That could be a disaster for, say, nonce generation. The solution would be to have multiple independent entropy pools and either bind them to

Yeah basically. That could be a disaster for, say, nonce generation. The solution would be to have multiple independent entropy pools and either bind them to cores(/sets of cores) or pick a non-busy one in a contention case.

acqq 13y ago
Yes, if there is no a urandom generator per core, it would be convenient for some extreme cases to introduce such. The question is if it's worth the effort and the resulted "bloat" of the kernel code and memory usage. Linux runs on some very small devices too and even there decent user-space programmers can easily do their own per-thread generation in their programs. Normal uses of crypto are such: you initialize your own crypto once, then produce a lot of data in your own space. If urandom is really "one for all cores" somebody should be able to demonstrate the speed drop by just writing some bash script? Volunteers?
- claudius 13y ago
  It seems to work in part. For /dev/urandom, I see always roughly the same throughput: $ time dd if=/dev/urandom of=/dev/null bs=1 count=10000000 real 0m10.640s user 0m0.696s sys 0m9.940s $ time (for i in $(seq 1 50); do dd if=/dev/urandom of=/dev/null bs=1 count=200000 2>/dev/null & done; wait) real 0m11.199s user 0m1.232s sys 0m42.828s $ time (for i in $(seq 1 500); do dd if=/dev/urandom of=/dev/null bs=1 count=20000 2>/dev/null & done; wait) real 0m11.234s user 0m1.252s sys 0m42.536s whereas for /dev/zero: $ time dd if=/dev/zero of=/dev/null bs=1 count=10000000 real 0m3.268s user 0m0.660s sys 0m2.604s $ time (for i in $(seq 1 50); do dd if=/dev/zero of=/dev/null bs=1 count=200000 2>/dev/null & done; wait) real 0m2.550s user 0m1.192s sys 0m8.760s $ time (for i in $(seq 1 500); do dd if=/dev/zero of=/dev/null bs=1 count=20000 2>/dev/null & done; wait) real 0m2.612s user 0m1.228s sys 0m8.112s Of course, the bash for-loop here together with the forking has some considerable overhead, so these values should likely be interpreted carefully (Linux 3.14-rc7, Core i5 520M).

acqq 13y ago

Yes, if there is no a urandom generator per core, it would be convenient for some extreme cases to introduce such. The question is if it's worth the effort and the resulted "bloat" of the kernel code and memory usage. Linux runs on some very small devices too and even there decent user-space programmers can easily do their own per-thread generation in their programs. Normal uses of crypto are such: you initialize your own crypto once, then produce a lot of data in your own space. If urandom is really "one for all cores" somebody should be able to demonstrate the speed drop by just writing some bash script? Volunteers?

claudius 13y ago
It seems to work in part. For /dev/urandom, I see always roughly the same throughput: $ time dd if=/dev/urandom of=/dev/null bs=1 count=10000000 real 0m10.640s user 0m0.696s sys 0m9.940s $ time (for i in $(seq 1 50); do dd if=/dev/urandom of=/dev/null bs=1 count=200000 2>/dev/null & done; wait) real 0m11.199s user 0m1.232s sys 0m42.828s $ time (for i in $(seq 1 500); do dd if=/dev/urandom of=/dev/null bs=1 count=20000 2>/dev/null & done; wait) real 0m11.234s user 0m1.252s sys 0m42.536s whereas for /dev/zero: $ time dd if=/dev/zero of=/dev/null bs=1 count=10000000 real 0m3.268s user 0m0.660s sys 0m2.604s $ time (for i in $(seq 1 50); do dd if=/dev/zero of=/dev/null bs=1 count=200000 2>/dev/null & done; wait) real 0m2.550s user 0m1.192s sys 0m8.760s $ time (for i in $(seq 1 500); do dd if=/dev/zero of=/dev/null bs=1 count=20000 2>/dev/null & done; wait) real 0m2.612s user 0m1.228s sys 0m8.112s Of course, the bash for-loop here together with the forking has some considerable overhead, so these values should likely be interpreted carefully (Linux 3.14-rc7, Core i5 520M).