From owner-freebsd-geom@FreeBSD.ORG Tue Jan 29 21:22:44 2008 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BC2C16A41A for ; Tue, 29 Jan 2008 21:22:44 +0000 (UTC) (envelope-from bsd@fluffles.net) Received: from mail.fluffles.net (fluffles.net [80.69.95.190]) by mx1.freebsd.org (Postfix) with ESMTP id 60DFC13C465 for ; Tue, 29 Jan 2008 21:22:44 +0000 (UTC) (envelope-from bsd@fluffles.net) Received: from [10.0.0.18] (cust.95.160.adsl.cistron.nl [195.64.95.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: info@fluffles.net) by mail.fluffles.net (Postfix) with ESMTP id 19D9EB29D6A for ; Tue, 29 Jan 2008 22:05:38 +0100 (CET) Message-ID: <479F959E.9080308@fluffles.net> Date: Tue, 29 Jan 2008 22:07:42 +0100 From: "fluffles.net" User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: freebsd-geom@FreeBSD.org References: <9e77bdb50801160832p39619f1fm85bf1454fead3357@mail.gmail.com> <9e77bdb50801170615l3ff6f6bbo97ade8b4471dc7b0@mail.gmail.com> In-Reply-To: <9e77bdb50801170615l3ff6f6bbo97ade8b4471dc7b0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Authentication with geom_eli X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 21:22:44 -0000 Cyrus Rahman wrote: > Here are some timings related to different encryption and > authentication algorithms. Although the authentication involves extra > copying and additional data being written to disk, it is clear the > algorithm is also quite significant. > > The system is a quad processor Q6600 running at 2.4GHz with mid-range > SATA disks. > You method is testing seems wrong to me. DD is using blocking or synchronous I/O (1 at a time, no parallelism), so your quadcore processor will not be utilized fully. You should always check top and gstat when benchmarking, to confirm there isn't an artifical bottleneck somewhere. You can use DD but you should not perform direct I/O but instead use the UFS filesystem with enough read-ahead, example: geli init .. newfs -b 32768 /dev/blabla.eli mount .. dd if=/dev/zero of=/path/to/mount/zerofile.000 bs=1m count=4000 then you have measured write speed, for read speed you *NEED* to unmount the volume first. This throws away the filecache, listed under "Inact" in the top output. : umount .. mount .. dd if=/path/to/mount/zerofile.000 of=/dev/null bs=1m Then you have read speed. Also test with enough read ahead: sysctl vfs.read_max=64 That will increase read ahead from 8 (default) to 64 blocks in my example blocks of 32KB, but default is 16KB. Ofcourse before testing this you should unmount again, or you'll get (partial) memory speed results exceeding disk capability, such as below for "cached read". Also make sure GELI is correctly configured to use all 4 cores: sysctl kern.geom.eli.threads=0 (0 means one thread for each CPU core) Confirm the load with top and see the throughput rise. :) For comparison Core 2 Duo 3.0GHz (dual core): tested using a malloc memory disk using mdconfig -a -t malloc -s 300m tested under FreeBSD 7.0 RC1 GENERIC i386 GELI with two threads, UFS 32k throughput read: 314572800 bytes transferred in 2.990616 secs (105186629 bytes/sec) cached read: 314572800 bytes transferred in 0.134842 secs (2332896522 bytes/sec) write: 314572800 bytes transferred in 2.788651 secs (112804650 bytes/sec) GELI with one thread, UFS 32k throughput read: 314572800 bytes transferred in 5.574472 secs (56430959 bytes/sec) cached read: 314572800 bytes transferred in 0.137468 secs (2288337051 bytes/sec) write: 314572800 bytes transferred in 4.984672 secs (63108023 bytes/sec) Hope you found this interesting, i'm fond of benchmarking. :) If you require any help or want more results be free to ask. Fine regards, Veronica