Date: Fri, 6 Aug 2004 13:35:38 +0200 From: "Daniel Eriksson" <daniel_k_eriksson@telia.com> To: <freebsd-current@freebsd.org> Subject: Simple BDE disc encryption benchmark Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAApKSdNgL8EkaHhtB/cG3DrwEAAAAA@telia.com>
next in thread | raw e-mail | index | archive | help
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=3D/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 Eriksson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAApKSdNgL8EkaHhtB/cG3DrwEAAAAA>