From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXOvE6he4Kgf for ; Thu, 28 Jul 2011 15:07:28 +0200 (CEST) Received: from mail-gw0-f43.google.com (mail-gw0-f43.google.com [74.125.83.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Thu, 28 Jul 2011 15:07:28 +0200 (CEST) Received: by gwm11 with SMTP id 11so2424727gwm.2 for ; Thu, 28 Jul 2011 06:07:27 -0700 (PDT) Message-ID: <4E315F0A.4050109@gmail.com> Date: Thu, 28 Jul 2011 09:07:22 -0400 From: =?ISO-8859-1?Q?Jorge_F=E1bregas?= MIME-Version: 1.0 References: <4E309CC0.6010706@gmail.com> <20110728051117.GB5441@tansi.org> In-Reply-To: <20110728051117.GB5441@tansi.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] LUKS & TrueCrypt - Speed Test List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 07/28/2011 01:11 AM, Arno Wagner wrote: > There is an old gemran egineering saying: > > "wer mist mist mist" > > (along the lines of "Those who measure measure crap") > I think it applies here. Hello Amo, I warned everyone that this wasn't a pro test :) At least, I laid down the specifics involved. > Real-time is tricky. It does not reflect effort invested. If you > look at the sys itime, you see that the crypto-effort is only about > 90 seconds more. Even that is pretty much below the measurement > error. I agree here. I shouldn't have paid much attention to real time. Nonetheless I'm still curious about the little difference... > Very likely the differences are due to storage differences > and do not show crypto-speed differences. I used the same external drive for both tests. > I suggest you run both tests at least 3 times and make sure > your storage is significantly faster than the crypto, e.g. > by doing this between RAM disks or SSD storage. Also a complex > disk access patterhn like rsync is not suitable as it may > have complex interactions with caching and buffering. I didn't want to go with sequential & random read/writes (with different block sizes etc) as I wanted a rough test out of the very same tool I use every day (rsync) with the same data on the same disk. I understand the crypto involved (CPU-wise) is much faster than the slow I/O of my external drive but that's what I have. Regarding repeating the test, I totally agree with that. Thanks for the input. Regards, Jorge