Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] TrueCrypt with SSD



Edward Ned Harvey <blu at nedharvey.com> writes:

>> From: Derek Atkins [mailto:warlord at MIT.EDU]
>> 
>> Dell Laptop (E6420) using Fedora's default-install dm-crypt
>> configuration.  The performance hit was in how long it took to copy
>> ~300GB of data from a USB (or eSata) drive.  When I did a similar copy
>> on an unencrypted ThinkPad it took a fraction of the time that it took
>> to copy it on the encrypted Dell.  Same Data.  The only differences were
>> the ThinkPad v. Dell, and encrypted v. non-encrypted.  Even the copy
>> method was using the same, on the same base OS.
>> 
>> I just dont recall if I had upgraded to 2.6.40 before or after copying
>> all the data....
>
> That's a plenty modern processor.  As I said, and others have said the same
> thing, the most cpu overhead you'll see, depending on your processor and the
> encryption algorithm, is 1%, 3%, 20%, 30%...  Never 100% and therefore never
> a slowdown resulting.  Unless you're doing something horribly wrong like
> AES-Blowfish-Serpent-whatever...  Quadruple encrypted 16M bits...  Or
> something horrible.
>
> I suspect your slow down is not caused by the encryption.  Or else there's
> something horribly wrong with your encryption.  Maybe you have the wrong USB
> drivers loaded and therefore the external drive is really slow... 
>
> Some tests that might shed some light on the subject ...
>
> Simply write a file.  Eliminate the possibility of external drive slowdown.
> time dd if=/dev/zero of=10Gfile bs=1024k count=10240

I did this a few times with various count sizes and noticed that the
speed declined significantly once I started writing more than my RAM
cache size data:

[warlord at mocana mocana]$ time dd if=/dev/zero of=/home/warlord/TestDataWrite bs=1k count=20000
20000+0 records in
20000+0 records out
20480000 bytes (20 MB) copied, 0.0662049 s, 309 MB/s
0.002u 0.063s 0:00.10 60.0%	0+0k 128+40000io 2pf+0w
[warlord at mocana mocana]$ time dd if=/dev/zero of=/home/warlord/TestDataWrite bs=1k count=200000
200000+0 records in
200000+0 records out
204800000 bytes (205 MB) copied, 1.77495 s, 115 MB/s
0.018u 0.606s 0:01.78 34.2%	0+0k 16+400000io 0pf+0w
[warlord at mocana mocana]$ time dd if=/dev/zero of=/home/warlord/TestDataWrite bs=1k count=2000000
2000000+0 records in
2000000+0 records out
2048000000 bytes (2.0 GB) copied, 45.2016 s, 45.3 MB/s
0.200u 6.273s 0:46.31 13.9%	0+0k 112+4000040io 1pf+0

> Run top during the process.  Watch to see if there's some other process
> competing for CPU.  Watch to see if the CPU ever reaches 100%.

Right now pretty much what's competing are dd, a bunch of kworker
processes, and kswapd.  I ran the last test a second time and got
54.9MB/s.  A third time and I noticed that flush was up there, too, and
only got 44.4MB/s.

> Eliminate encryption entirely.  Just read the file and dump to the bin...
> time cat /media/usb-external/bigfile > /dev/null

Well, I was using 'tar', but honestly I think I can ignore the USB/eSata
part based on the fact that I'm only seeing ~50MB/s for large-data
writes.  Alas, I cannot really test a raw write to this disk w/o
encryption.

Still, 50MB/s is a SIGNIFICANT reduction in I/O throughput from what I
think I should be seeing w/o encryption.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org