My mistake, that was a SAMSUNG SP2504C not a HD300LJ. Not that I imagine there'd be much difference. On 9/6/07, Roscoe <eocsor@xxxxxxxxx> wrote: > 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
