On Wed, 2005-01-19 at 12:03 -0500, Bill Davidsen wrote: > On Tue, 18 Jan 2005, Dan Hollis wrote: > > > On Tue, 18 Jan 2005, Venkat Manakkal wrote: > > > As for cryptoloop, I'm sorry, I cannot say the same. The password hashing > > > system being changed in the past year, poor stability and machine lockups are > > > what I have noticed, besides there is nothing like the readme here: > > > > cryptoloop is also unusably slow, even on my x86_64 machines... > > I'm obviously doing something wrong, I just copied about 40MB of old > kernels (vmlinuz*) and some jpg files into a subdir on my cryptoloop > filesystem, and I measured 4252.2375kB/s realtime and 18819.7879 kB/s CPU > time. This doesn't seem unusably slow, even on my mighty P-II/350 and > eight year old 4GB drives. The hdb is so old it has to run in pio mode, to > give you an idea, and the original data was not in memory. I've rewritten some CBC code to fit the facilities I introduce in my LRW patch[1]. Here are the results for my P4@xxxxxx: loop-aes, CBC: ~30.5mb/s dm-crypt, CBC prior to my rewrite: ~23mb/s dm-crypt, CBC with my LRW patch: ~27mb/s dm-crypt, LRW with my LRW patch: ~27mb/s (slightly faster than CBC) As you can see my LRW patches (actually it's the generic scatterwalker which is part of the LRW patch set) halves the gap to loop-aes. I'm sure dm-crypt is never going to achieve the speed of loop-aes. That's just the price you pay, when you have to do things right and clean, so they get merged into main. Kernel developers are choosey customers, you know. [1] http://clemens.endorphin.org/patches/lrw/ -- Fruhwirth Clemens <clemens@xxxxxxxxxxxxx> http://clemens.endorphin.org
Attachment:
signature.asc
Description: This is a digitally signed message part
