getting garbage faster using FreeBSD?

[Volker]

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