mersenne twister has a ginormous periodicity that's very hard to even get a value for on a machine without using pari/GP. my understanding is that mt19937 (nmersenne twister) from
#include <random> in c++ is more like http://www.cplusplus.com/reference/random/mersenne_twister_engine/ and http://www.cplusplus.com/reference/random/mt19937/
w=32 n=624 which states the periodicity (using ttcalc) is (2^((n-1)*w)-1)/32=(2^((624-1)*32)-1)/32=big huge huge number - cpu internals can't handle that size of a number without truncating it to some ridiculously small number. so let's find out the number of digits for that periodicity: ceil(log(abs((2^((624-1)*32)-1)/32)+1;10)/log(10;10)) = 6000 digits worth of number. even ttcalc only goes up to 99 digits. togiveyou an idea, 2^64=18,446,744,073,709,551,616 and is calculable with cpu instructions, but not even the IEEE754 FPU in your processor can handle this size of number. this is where you get into bignum math and number-theory calculators like pari/GP that can handle stuff to 10,000 digits easy - and print it too.
my understanding of /dev/urandom and /dev/random is that they are very poor for long runs like wiping disks and should not be used for steady streams of random numbers only for single-number-acquires like passwords and other crypto, etc.
for better performance on a disk wiping program, maybe nwipe or writing your own c++ utility would be a good idea that uses mt19937 (it's slow, but effective). you can truncate the 32 bits to just 8 or double your bandwidth by using 16 bits worth the 64-bit mt19937 should give you 32 bits worth (same - should write a bug report about the implementation problem in gcc). the upper bit is useless, I guess they figured everybody was going to use a signed number and never use negative numbers. the
<random> c++ template library should accommodate both signed and unsigned data types, not just signed.
best thing would be to write a c++ program. I think wipe as an idea is flawed based on http://linux.die.net/man/1/shred and http://linux.die.net/man/4/urandom under Usage where it says "It is designed for security, not speed, and is poorly suited to generating large amounts of random data."
if the only thing you were worrying about was periodicity (distance between repeated patterns), I don't think this is a problem. cryptography is not one of my specialties, but
my understanding of the NIST wipe is you should do something like 8 or 15 passes of MT, to get the magnetic ghost images down to a minimum. the more the merrier of course, but probably with diminishing returns the more you do.
not sure what this kind of stress does to the drive. be carefulwhat usb dock you use, startech SATDOCKU3SEF was the only one I found with a nice and usable fan on it (crank up to max) should this be necessary.
also, I like parallelizing jobs to save time. just stickan & on the end of the command and do as many jobs as you have channels. it willuse 1 thread per job. if your server has 120 threads(4cpux30T), then you can have up to 120-1 jobs, leaving 1 for the system. tocheckon the jobs, use the jobs command,and ITHINK towait forthejobs todoashutdown orwhatever use the wait command. like
wait ; shutdown -r 0
I am still trying to figure out how to make use of the
foreach command with `ls /dev/disk/by-id there must be a bug in BASH because towipe everything from a livecd I should be able to wipe all disks with
I am developing a web page at