GS80:DLT80 performance.

[Learn_1]

i was using DS-TLZ10-VA (SBB)drive (DDS3 data cartridges)for backup purpose in GS80 server.Now we have installed DS-TZ90N-VW (SBB) drive and started by backing up data.the backup process that used to complete in 9 hours by using DS-TLZ10-VA drive is now taking more than 13 hours by using DS-TNZ90-VW 40/80GB DLTSCSI tape drive (DLT4 data cartridge).compression is disabled.
can anybody explain what could be the reason and mention the data backup rate of both drives.

[labadie_1]

Hello

It would be interesting to know your Vms version. Anyway, to have a good throughput you need to "feed" the tape quickly enough, so you must have a backup account, with good quotas for backup, as in the doc (on this mirror of the doc

http://pi-net.dyndns.org/docs/openvms0731/731final/6017/6017pro_046.html

search for the string
11.7 Setting Process Quotas for Efficient Backups

The throughput depends on your data (binary files, text files, .exe...) when you use the compression.

You should monitor the system during the backup:

is the Cpu saturated ?
do you have a big queue length on the disks ( $ monitor disk/item=queue) ?

And check you have the last patches for backup and fibre-scsi.

regards

Gerard

[Learn_1]

Hi All,
1.The OS is Openvms7.3-1
2.There is no cpu saturation or quota limit problem.with the same quota and processor ,the backup was functiong on DDS3 quickly.
according to DLT80 documentation the transfer rate is 6.0 MB/s and of DDS3 1.2MB/s.with reference to this documentation the backup process on the DLT should complete quickly as compared to DDS3.
IS there any firmware update or patch is neede to overcome this problem.current system version is V6.3-82 & VMS Pal code is 1.96-6.
Please update on this issue?

[Alex Daniels]

Certainly wouldnt expact the DLT to take longer.

How is the DLT attached ? Direct SCSI, via a MDR ?

How are the the disks attached, fibre, scsi ?

Are the disks/tape drive on the same SCSI bus or coming though the same fibre HBA ?

Consider moving the tape to a different SCSI bus/HBA if it appears the bottleneck is there.

How much data are you backing up, hard to say how good/bad the 9/13 hours are without knowing this.

Sounds like the tape drive is not streaming as you arent getting data to it fast enough.

Can you post the format of your backup command.

Look specifically at the block size, think default is 8192. As VMS will be doing ackknowledgments on the packets you will be artifically chocking the thoughtput by using low block sizes. I suggest doing a number of test backups of the same disk with different sizes until you find the most efficent value.

[Learn_1]

Hi
disks are attached with the system via fiber as the disks are in MSA8000 storage connected via HSG80 controller.
disks and tape are on the different bus.

i am attaching the procedure that is being used for backing up data.in this procedure /media=compact is being used where as compression is already enabled on the DLT80.could this be a reason as compression is being used twicw.

[Alex Daniels]

As the tape is on a seperate SCSI, and the disks are fibre via a HSG80 there should be no issues of contention or bottlenecks on HBA.

In terms of enabling compression doesnt matter that you specify /media=com even though the light may already be on, on the drive.

However using compression is not the best thing if a quick backup is what you are after. There is a overhead in compressing the data, this can stop the drive streaming and slow the backup.

If the data you are backing up is already compressed (ie executable images and the like as opposed to text) then this is even more the case. You can even in this senerio get more space taken up than if you didnt use compression.

As a way forward I suggest doing a test backup without compression and with a considerably larger block size (/block=...). Am sure you would get improved times.

[Michael Stephan]

hi,

I have a similar configuraten: ES40, HSG80, 40/80GB DLT extern.

I have to Backup 7 GB and it takes about 20 min.

My statement is:
BACKUP /BLOCK_SIZE=32256 /MEDIA_FORMAT=COMPACTION /LABEL=xxx $1$dga1:[000000...]*.* DLT:DGA1.BCK/SAVE

Very important: listening to the DLT, I hear a continuous 'ssssssss', not a 'ssss ss ssss ss'


Michael

[Dirk Bogaerts]

Hi,

I had exactly the same disappointing experience when moving from a TZ88 to a DLT8000 tabletop (which is very comparable to the TZ90N) on a DS20.
Two things made the DLT8000 performance finally much better:
1) adding /BLOCK_SIZE=65535 to the backup procedure. This makes a big difference (even for the backup's done on remaining TZ88's). It's a pitty, higher blocksize value's aren't allowed in Backup, as the 40/80 DLT's could even 'stream' the data faster with bigger blocks.
2) check the supported options list; as for the DLT8000, HP restricted the allowed SCSI-cards between the time I had ordered the DLT8000 and the delivery of the Drive (some 1.5 years ago if I remember well). My independant hardware vendor, gave me a new compatible SCSI card for free, after I proved to them what had been going on with HP's 'supported options list' for the DS20. Maybe on the GS80 similar restrictions exist for the DLT40/80 hardware ??

And indeed as Micheal commented, this device needs to be kept 'streaming'; it's much more important than on the older DLT or DDS devices. So the longer the ssssssss's are and the less streaming-interruptions you hear, the better. But of course, it's easier to 'monitor' the ssssssss's of an external tabletop, than on a SBB ;-)

Dirk

[Antoniov.]

Hi Anwar,
there are a few reason for your performance; you can read this similar question http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=221387.
Remember:
a) DLT4 is faster than TLZ but require a greater time to start; so if device stop and restart continously, backup go slow; I read your attachment and I think it's better use mount /fore.
b) DLT4 work better with large block size.

Bye
Antoniov