From owner-freebsd-stable@FreeBSD.ORG Mon Feb 19 21:56:05 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E68F516E05C for ; Mon, 19 Feb 2007 21:56:05 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id A0E8313C474 for ; Mon, 19 Feb 2007 21:56:05 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7cff.q.ppp-pool.de [89.53.124.255]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 0A611128841; Mon, 19 Feb 2007 22:55:58 +0100 (CET) Received: from [192.168.16.3] (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id B6BC02E5F2; Mon, 19 Feb 2007 22:55:49 +0100 (CET) Message-ID: <45DA1CE4.4020202@vwsoft.com> Date: Mon, 19 Feb 2007 22:55:48 +0100 From: Volker User-Agent: Thunderbird 1.5.0.9 (X11/20070119) MIME-Version: 1.0 To: Kris Kennaway References: <45D9FD35.6040702@vwsoft.com> <20070219195143.GA42379@xor.obsecurity.org> <45DA121E.1040803@vwsoft.com> <20070219212532.GA43496@xor.obsecurity.org> In-Reply-To: <20070219212532.GA43496@xor.obsecurity.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: freebsd-stable@freebsd.org Subject: Re: getting garbage faster using FreeBSD? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 21:56:06 -0000 On 02/19/07 22:25, Kris Kennaway wrote: > On Mon, Feb 19, 2007 at 10:09:50PM +0100, Volker wrote: >> On 02/19/07 20:51, Kris Kennaway wrote: >>> On Mon, Feb 19, 2007 at 08:40:37PM +0100, Volker wrote: >>>> I suspect this to be a slow /dev/random. >>> This sounds odd to me, I get 18-20MB/sec sustained read performance >>> from /dev/random on this 2GHz system, which is probably faster than >>> your tape write speed. >> Hmm, so this might be the tape drive(r)? I'll check this out as soon >> as I'm going to write to hard disk. >> >> I'm going to make some tests with /dev/random to get the real speed. > > Yes, it could be - you should do some more tests to find out where > your bottleneck really is before trying to possibly optimize the wrong > thing. > >>>> As there is medical data on all media I really need garbage >>>> (/dev/zero wouldn't be enough for data security as this might get >>>> recovered). >>> Neither would a single pass with /dev/random, but you presumably knew >>> this. >> Yes, I know... I would like to run 5 or more passes if it's not that >> slow. >> >> Do you think playing with randoms' sysctl interface might influence >> performance? Does /dev/random automatically re-seed from time to >> time or is it seeded at boot time only? > > It re-seeds continuously, see random(4) and/or the yarrow > specification. Don't frob the sysctls until you have confirmed that > /dev/random is really your problem though. Kris, ok and thanks - it has been the person in front of the computer, who has been too stupid (could it be me??). I've played a bit on that machine using /dev/random to /dev/null and used different blocksizes. The results are somewhat around 33MB/sec (with blocksizes between 1M and 8M). Now I've played with different blocksizes while dd'ing /dev/random to the hard disk and getting similar results. dd'ing to the tape drive gives best results with blocksizes around 64k. Using blocksizes with 1k gives 230KB/sec, 8k gives 1.7MB/sec. The tape drive did not stream well and I guess that (too short block sizes) has been my problem. Now it performs well. Sorry for sending my stupidity to the list. ;) Thx, Volker