getting garbage faster using FreeBSD?
wmoran at collaborativefusion.com
Tue Feb 20 18:00:53 UTC 2007
In response to Kris Kennaway <kris at obsecurity.org>:
> On Tue, Feb 20, 2007 at 09:12:38AM -0500, Bill Moran wrote:
> > In response to Volker <volker at vwsoft.com>:
> > > 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.
Collaborative Fusion Inc.
More information about the freebsd-stable