From owner-freebsd-stable@FreeBSD.ORG Tue Feb 20 18:00:53 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 2787316A52A for ; Tue, 20 Feb 2007 18:00:53 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id D30F913C4A3 for ; Tue, 20 Feb 2007 18:00:52 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Tue, 20 Feb 2007 13:00:52 -0500 id 00056424.45DB3754.0000696B Date: Tue, 20 Feb 2007 13:00:51 -0500 From: Bill Moran To: Kris Kennaway Message-Id: <20070220130051.bfcf6cf2.wmoran@collaborativefusion.com> In-Reply-To: <20070220165012.GB75535@xor.obsecurity.org> References: <45D9FD35.6040702@vwsoft.com> <20070219195143.GA42379@xor.obsecurity.org> <45DA121E.1040803@vwsoft.com> <20070220091238.c04cfceb.wmoran@collaborativefusion.com> <20070220165012.GB75535@xor.obsecurity.org> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.0 (GTK+ 2.10.9; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Volker , 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: Tue, 20 Feb 2007 18:00:53 -0000 In response to Kris Kennaway : > On Tue, Feb 20, 2007 at 09:12:38AM -0500, Bill Moran wrote: > > In response to Volker : > > > > > On 02/19/07 20:51, Kris Kennaway wrote: > > > > On Mon, Feb 19, 2007 at 08:40:37PM +0100, Volker wrote: > > > >> The tape sits there since 48 hours writing a block of data every > > > >> other minute and still didn't fill up the tape completely. The > > > >> system this is running on is a P-4 3GHz machine using FreeSBIE 2.0 > > > >> (6.2-RELEASE based). > > > >> > > > >> 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. > > > > Are you actually using /dev/random and not /dev/urandom? > > > > /dev/random is "military grade" random data. It will block if it feels > > that it hasn't gathered enough entropy to satisfy your request. It will > > never provide random data at any reasonable speed, but it will provide > > high-quality random data. > > > > If you need lost of random data, use /dev/urandom, which provides data > > that _may_ be predictable under some circumstances, but will provide > > it at a decent rate of speed. > > Not true in a post 4.x world, they are symlinks and both "military > grade" with non-blocking semantics. Interesting ... I could swear I recently had a problem with /dev/random blocking on a 6.X system ... I'll have to take another look. -- Bill Moran Collaborative Fusion Inc.