Hi! I just ran a very simple benchmark on the GBDE disc encryption in CURRENT. The benchmark setup looked like this: * Slow machine (Celeron 366, 128MB mem) * 5-CURRENT from yesterday, running off of some old ATA disc * 2 x 9GB 10k rpm SCSI discs hooked up to an Adaptec 2940 The benchmark was to copy the /usr directory (copied from the ATA disc, 1.7GB) or a directory containing big files (/bigfiles, 1.7GB in 16 files created by 'dd if=/dev/random ...') from scsi disc 1 to scsi disc 2. I ran each benchmark twice and took a simple average of the results. unencrypted to unencrypted: /usr : 697 real 10.6 user 235 sys (~50% idle) /bigfiles: 123 real 0.4 user 84 sys (~25% idle) unencrypted to encrypted: /usr : 1778 real 10.7 user 236 sys (~35% idle) /bigfiles: 379 real 0.4 user 82 sys (~10% idle) encrypted to encrypted: /usr : 1978 real 11.6 user 242 sys (~25% idle) /bigfiles: 615 real 0.4 user 80 sys (0% idle) The only time the CPU was completely busy was when copying /bigfiles from encrypted to encrypted. My question is: Why does the it take so much longer when encryption is involved even though 'top' seems to think there are CPU cycles left to burn? /Daniel ErikssonReceived on Fri Aug 06 2004 - 09:35:37 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:05 UTC