My two cents: SAMSUNG HD300LJ, AMD X2 3800 [2x 2GHz], 2048MB DDR-6400, NF570Ultra Linux 2.6.18, Debian AMD64, cbc-essiv:sha256 # zcav /dev/mapper/chome #loops: 1, version: 1.03 #block K/s time 0 44420 2.305267 100 44751 2.288180 200 44897 2.280745 300 45291 2.260896 400 45249 2.263011 # zcav /dev/sdb1 #loops: 1, version: 1.03 #block K/s time 0 69751 1.468063 100 70936 1.443549 200 71351 1.435157 300 72180 1.418669 400 73036 1.402036 ...So, say around 37% slower as a result of dm-crypt. I don't really notice it much as a desktop user :) On 9/6/07, Wolfgang Sailer <Wolfgang@xxxxxxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > > I don't think that hdparm is a good way to test the performance of a LUKS > partition, as - I think - hdparm only tests the reed speed of a device, not > of a partition. I.e. If you test a drive with it, I think it reads raw data > without decrypting it. > > To test the decryption speed you could use a timed copy of a file to /dev/null: > # time cp sourcefile /dev/null > should give you the overall net performance. > Comparing a sourcefile on an unencrypted with an encrypted partition should > give you an idea how LUKS slows your system down. > > To give you a comparison, here are my performance data: > Any comments on improving the test methodology are welcome! > > I have a Pentium 3 800 MHz CPU, 640MB of RAM. > I use a RAID 5 setup of 4 80GB Seagate Barracuda 4 disks to build a > partition which is LUKS encrypted and a 20GB Seagate Barracuda 4 disk as a > system disk, not LUKS encrypted, with encrypted swap. > I operate 2 of my RAID disks + the system disk from the on-board controllers > and the other 2 from a promise PCI IDE controller with 2 channels. > The 4 80GB disks are RAID-5-ed to /dev/md2 and on this partition I cerated a > LUKS volume /dev/mapper/luks1 > > > I did a series of tests to evaluate the performance: > > 1: I tested the performance of the disks with hdparm: > Typically, each one of my Seagate drives gives a read performance of 20MB > (on board controller) to 40MB (PCI controller) > # sudo hdparm -t /dev/hd[a-x] > /dev/hda > Timing buffered disk reads: 62 MB in 3.09 seconds = 20.04 MB/sec > /dev/hde: (Controller prim master) > Timing buffered disk reads: 122 MB in 3.05 seconds = 40.01 MB/sec > Also, I tested it by reading 500MB of raw data from the disks: > # sudo dd if=/dev/hd[a-x] of=/dev/null bs=5000000000 count=1 > It gives the same 20-40 MB/sec > > 2: I tested the performance of the RAID 5 system UNENCRYPTED by reading from > /dev/md2: > # sudo dd if=/dev/md2 of=/dev/null bs=500000000 count=1 > 500000000 bytes (500 MB) copied, 12.5872 seconds, 39.7 MB/s > So, I can read at 40MB/s from the RAID 5 array, system, which is good. > > 3: I tested the influence of encrypting with LUKS: this time the input file > is the luks partition /dev/mapper/luks1 > # sudo dd if=/dev/mapper/luks1 of=/dev/null bs=500000000 count=1 > 500000000 bytes (500 MB) copied, 38.7348 seconds, 12.9 MB/s > So, performance is down to 13MB/sec by encryption. > > 4: to verify this, I copied actual files from the LUKS volume to Nirvana: > # time cp "some 700MB file from the luks partition" /dev/null > 730322944 bytes, 56.435 = 12.34 MB/sec > So, the results of dd and cp agree well. > > 5: my linux box servs as a NAS, so I also copied the same file to one of my > client computers running also linux over a 100MB LAN: > # time cp "some 700MB file on the LUKS NAS" /dev/null > 730322944 bytes, 83.73 sec = 8.3 MB/sec > What can be expected from an 100MBit Ethernet connection, taking protocol > overhead into account. > > Conclusions: > My 800MHz CPU is fine for RAID-5 XOR calculations. > The LUKS encryption slows it down considerably, from 40 to 13 MB/s > It still suffices to saturate the ethernet bandwidth. > To do better, 1st gigabit ethernet and 2nd a faster CPU would be needed. > > If I haven't misunderstood something fundamental completely, my tests could > help you benchmark your system. > > Greetinx, > Wolfgang > > Tomasz Chmielewski wrote: > > I just set up an encrypted LUKS device using the information on > > http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptedDeviceUsingLUKS > > > > There was a suggestion there, which prompted me to check the performance: > > > > If you wish, use /sbin/hdparm to benchmark. However my benchmarks on > > an AMD Athlon 3200 indicate no great difference between an encrypted > > and a normal unencrypted partition. > > > > > > First, I set read-ahead to the same value on both devices (original LVM > > device, and the crypted one): > > > > # blockdev --setra 16384 /dev/mapper/crypttest > > # blockdev --setra 16384 /dev/mapper/san1-test > > > > > > Next, hdparm test: > > > > # hdparm -t mapper/crypttest mapper/san1-test > > > > mapper/crypttest: > > Timing buffered disk reads: 116 MB in 3.01 seconds = 38.54 MB/sec > > HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate > > ioctl for device > > > > /dev/san1/file1-swap: > > Timing buffered disk reads: 304 MB in 3.12 seconds = 97.46 MB/sec > > HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate > > ioctl for device > > > > > > So, this quick test suggests that with a crypted device, I get about 40% > > performance of the original LVM volume? > > > > > > My setup is hardware RAID-10, and a dual core 3 GHz Xeon. > > > > Is it normal? I would say yes, as both cores use 100% CPU when I do > > intensive reads from an encrypted volume. > > However, this seems to contradict with "However my benchmarks on an AMD > > Athlon 3200 indicate no great difference between an encrypted and a > > normal unencrypted partition". > > > > > > I used aes-cbc-essiv:sha256 cipher. > > > > Perhaps, I should use something lighter? > > > > > > > > - -- > Poets say science takes away from the beauty of the stars - mere globs > of gas atoms. Nothing is 'mere'. I too can see the stars on a desert night, > and feel them. But do I see less or more? > Richard P. Feynman > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFG3r7uR6b2EdogPFsRApx2AJ9P6GYAeNrQ8y1DBfpzasB9AO61pgCeLtQi > kITo6wDBPkuj6Js5DCQbIjU= > =z9Ju > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ > To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx > For additional commands, e-mail: dm-crypt-help@xxxxxxxx > > --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
