Craig White wrote:
> On Wed, 2009-01-07 at 17:57 +0100, Ralf Gross wrote:
>> T. Horsnell schrieb:
>>> Ralf Gross wrote:
>>>> Ferdinando Pasqualetti schrieb:
>>>>> I think you should use /dev/random, not /dev/zero unless hardware 
>>>>> compression is disabled in order to have more realistic figures.
>>>> This wouldn't be a good idea, /dev/random or /dev/urandom are just too
>>>> slow in generating random data. To test the nativ speed of the  drive
>>>> creating a file from /dev/urandom and writing this file then from
>>>> tmpfs or a fast disk to the drive would be much better.
>>>>
>>>>
>>>> Ralf
>>> Personally, I'd use /dev/zero with compression turned off.
>>> Then there's *nothing* between the data-source and the tapedrive.
>> Yes, but most people use hardware compresion with LTO drives. Sooner
>> or later he has to test the drive with compression.
> ----


> funny thing is that amanda developers are adamant that you disable
> hardware compression and use software compression instead.
> 
> Obviously it takes longer and more cpu power to compress the files in
> software before storing them on the tape and if you leave hardware
> compression on and use software compression too, the files probably grow
> in size.
> 
> Commercial backup software just seems to always use hardware
> compression.


IMO, using hardware compression makes it very difficult to investigate
performance problems. I spent a long time investigating my LTO4 performance,
varying the blocking factor, with and without hardware compression, and with
and without software compression, on an otherwise idle box.
I never reached any firm conclusions.

It seemed to me that hardware compression could result in the tapedrive
mechanism not being fed data fast enough to keep it streaming at full speed,
since the records may be shortened by the compression process,  whereupon
it would slow down a bit by bit in order to avoid stopping altogether
(a really bad thing which results in shoe-shining motion) until the data
rate increased again, at which point it would accelerate. Without an increase
in that data rate, some threshold would be reached whereby the drive buffer
was exhausted and the tape would then begin stop-start/ing, and thus *really* 
slow down.

If you feed it with pre-compressed data, assuming you can compress fast enough
(which neither gzip nor bzip could if my LTO4 tests were anything to go by) then
the above process doesnt happen, and the tape can run at full speed always.

My feeling also, is that faster drives can sometimes result in slower throughput
because of the increased likelyhood of this stop-start.

Cheers,
Terry




------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users