Cela dit j'ai refait les tests avec /dev/urandom et /dev/random
Hair:~ otta $ time dd if=/dev/urandom of=/Volumes/Data/toto.bin bs=512k count=1200
1200+0 records in
1200+0 records out
629145600 bytes transferred in 60.276656 secs (10437633 bytes/sec)
real 1m0.973s
user 0m0.004s
sys 0m59.471s
Hair:~ otta$ time dd if=/dev/random of=/Volumes/Data/toto.bin bs=512k count=1200
1200+0 records in
1200+0 records out
629145600 bytes transferred in 53.121547 secs (11843511 bytes/sec)
real 0m53.393s
user 0m0.003s
sys 0m52.576s
Hair:~ otta $ ls -l /dev/*rand*
crw-rw-rw- 1 root wheel 13, 0 14 jan 22:00 /dev/random
crw-rw-rw- 1 root wheel 13, 1 18 oct 16:25 /dev/urandom
Pas de lecteur CD sous la main, macbouc air, toussa.
On constate qu'effectivement c'est plus long et qu'un core du CPU est au taquet. Cela dit 10 Mo d'aléas "cryptographique" par seconde (/dev/random vs /dev/urandom) , c'est très (trop?) rapide. Je me demande si le bazard n'a pas un générateur de bruit matériel (avec un linux et sans générateur on serait tombé très rapidement à quelques octets par seconde voire moins sur /dev/random) ou si le générateur est tout pourri.
[^] # Re: d'autres options peuvent etre utiles
Posté par oinkoink_daotter . En réponse au message vitesse de récupération avec ddrescue. Évalué à 1. Dernière modification le 14 janvier 2013 à 22:19.
Cela dit j'ai refait les tests avec /dev/urandom et /dev/random
Pas de lecteur CD sous la main, macbouc air, toussa.
On constate qu'effectivement c'est plus long et qu'un core du CPU est au taquet. Cela dit 10 Mo d'aléas "cryptographique" par seconde (/dev/random vs /dev/urandom) , c'est très (trop?) rapide. Je me demande si le bazard n'a pas un générateur de bruit matériel (avec un linux et sans générateur on serait tombé très rapidement à quelques octets par seconde voire moins sur /dev/random) ou si le générateur est tout pourri.
Fin du hors sujet.