Hi Paul,

        here are the two different typedefs, one for the 160Mb/s and one for
the 320Mb/s SCSI-controller. In both cases HWC was enabled.


This is the output, I used the very same tape for both runs:
(I did a full run, not only the compression check, -c ):


define tapetype LTO3_160 {
        comment "just produced by tapetype prog (hardware compression off)"
        length 386048 mbytes
        filemark 0 kbytes
        speed 65651 kps
}


define tapetype LTO3_320 {
        comment "just produced by tapetype prog (hardware compression off)"
        length 386048 mbytes
        filemark 0 kbytes
        speed 65303 kps
}


Not only the 'amtapetype' did not recognized HWC as you assumed, but the
transferrate with the faster controller is even little smaller than with
the slow controller.
Don't have a clue on that yet.


        Ralf





Paul Bijnens schrieb:
> On 2007-08-14 04:18, Ralf Auer wrote:
>> Hello everybody,
>>
>>     if you don't mind, I have two questions concerning hardware
>> compression.
>>
>> I have two HP Ultrium 960 drives. Up to now I used them with hardware
>> compression disabled and compressed my data on the clients.
>>
>> Now I enabled hardware compression and ran amtapetype.
>>
>> 1. The manual says (in Question 12):
>>
>> "Reasons to run amtapetype for your device:...
>> - You want to determine if your device has hardware-compression
>> enabled...
>>
>> and some websites also claim that 'amtapetype' should print a warning
>> message when HWC is enabled. For some reason, it does NOT on my tape
>> server. It also reads "hardware compression off" in the final output:
>>
>> define tapetype LTO3-HWC {
>>     comment "HP StorageWorks 960 LTO3 (hardware compression off)"
>>     length 386048 mbytes
>>     filemark 0 kbytes
>>     speed 65033 kps
>> }
>>
>> I checked HWC several times with standard Unix- as well as with official
>> HP-software, so that I can say for sure that HWC is now enabled but not
>> recognized by 'amtapetype'. (I used Amanda 2.5.2p1 and 2.4.5p1)
>> Should I worry about that?
> 
> Jon explained already that the compression algorithm in LTO is
> intelligent enough to avoid expanding compressed data.
> So the amount of data that amtapetype prints will be the same in both
> cases (because amtapetype tests the capacity with uncompressable data).
> 
> But amtapetype should actually detect the hardware compression, unless
> your tapedrive is too fast for the bus.
> Amtapetype detects hardware compression by comparing the write speed
> of very compressable data versus uncompressable data.
> Because the write speed of tape is usually limited by the bits written
> to the physical tape, amtapetype can measure the effect of compression
> inside the tapedrive, by feeding lots of very compressible data, and
> measuring the time it takes to write that to tape.
> If the computer is too slow feeding the data to the tapedrive, this
> process fails of course.  Because now the rate is limited by the bus,
> instead of the physical tape writing, amtapetype cannot notice that
> difference anymore.
> 
> You can run the compression test separately with the option "-c".
> That takes only a few minutes at most.
> 
> I believe the native speed of an LTO-3 is 80 MB/sec?  And you
> get 65 MB/sec, which is reasonably good.
> So I don't understand why the compression-test does not work...
> 
> 

-- 

Ralf Auer       
Physics Institute IV                    Office: 2.137
University of Erlangen-Nuremberg        Phone:  +49-9131-8527087
Erwin-Rommel-Str. 1                     Fax:    +49-9131-15249
D-91058 Erlangen, Germany               Ralf.Auer AT physik.uni-erlangen DOT de