Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 | |
We also thank MIT for the use of their facilities. |