DLT8000 BACKUPS TWICE AS SLOW AS TZ88(DLT4000) BACKUPS??!!

[Markus Waldorf_1]

The is also an old topic in the forum "slow DLT8000 and a fix please". http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=623897

" My customer has complained that when HP upgraded the firmware on their DLT8000 the backup times doubled. Hp then retro installed an older version of the firmware and things are back to normal. They have been told they need to get to the latest revision but are reluctant becuase of the speed issues."

[Jessie Bunker-Maxwell]

Jon, the backup utility blocksize qualifier definitely made a difference. I need to do more testing to determine if a different scsi card might help or if we're now getting the max throughput we can expect from this tape drive on our system, but I will be away from the office until June 11th, so will have to wait on that. Thank you so much for all your help.

Jess

[Jessie Bunker-Maxwell]

Markus, could you tell me how to check the parity setting on the scsi card and the tape drive? Jon's blocksize suggestion has made a huge difference in the backup time, but when I return to the office on June 11th, I will have more time to do additional testing and will use diag to look at what's happening. Thank you for your suggestions and pointing me to the tape drive firmware issue.

Jess

[Jon Pinkley]

Jess,

My guess is that the SCSI card probably won't make big difference. Before spending the money, you want to verify that the bottleneck is really the card. Timing a backup to the null device will give you a close approximation to the "best possible" time to read the data off the disk. There are some things that can be done to turn the authorization quotas for the username that is used for your backups, and that an affect how long it takes to backup a disk with many small files. It may be that the reading from disk is the your limiting factor, and if so, buying a faster SCSI card isn't going to speed things up significantly.

Using a large blocksize is good for several reasons, mostly reducing the per-I/O overhead.

It reduces the number of I/O operations needed, and the associated driver related setup needed for each $QIO operation.

It utilizes the SCSI bus better, as each I/O operation requires arbitration for the SCSI bus. This increases the maximum throughput possible for a given SCSI bus, in a similar way to using a larger Ethernet packet size will allow higher throughput than a smaller packet will.

Concerning DLT8000 Firmware, you can find what version is loaded using the following command:

$ pipe mcr sys$etc:scsi_info mkd600 | search* sys$pipe "Vendor Identification :","Product Identification:","Product Revision Level:"

The "Product Revision Level:" reflects the firmware loaded.

We have two DLT8000's, the one we just bought off eBay has

$! Vendor Identification : COMPAQ
$! Product Identification: DLT8000
$! Product Revision Level: 0250

Our other one has

$! Vendor Identification : COMPAQ
$! Product Identification: DLT8000
$! Product Revision Level: 0259

I am not sure what the latest firmware is. Both "seem" to work fine, although there are probably bugs fixed in newer versions.

The LTT utility can upgrade firmware, but make sure you understand the implications, and if at all possible do the upgrades when the drive/host are connected to a UPS (uninterruptible power supply).

Use the forum search for LTT for other threads discussing the tool.

Jon

[Markus Waldorf_1]

Hi, I would rather not change the default settings of the KZPDA scsi card, in particular since it seems to work fine with the old tape drive. Google for "Quantum DLT8000 Jumper Settings" should show you the link. If I remember correctly a parity mismatch will also show you ghost devices, ie. the drive device will show up several times.

Some scsi drivers will automatically slow down performance if there are errors on the bus. I would make sure to use the correct SCSI terminators and don't attach any scsi-2 or other devices on the same bus that are sync/async and have different latency like HD's. You may also want to check that none of the pins of the cables are bend, which can happen easily.
Best regards,
Markus

[Jon Pinkley]

Jess,

There is a bit more to the firmware than what I stated in my last comment.

http://www.quantum.com/ServiceandSupport/SoftwareandDocumentationDownloads/DLT8000/JumperSettingsDLT8000/Index.aspx

http://www.quantum.com/ServiceandSupport/SoftwareandDocumentationDownloads/DLT8000/PartNumbersDLT8000/Index.aspx

http://downloads.quantum.com/dlt8000/dlt8000productmanual.pdf

The product manual has the SCSI commands that are supported by teh DLT8000. Look at the data returned by the INQUIRY command for the details about the firmware.

By the way, how much of a difference in elapsed time did changing the blocksize make? Just curious.

Jon

[Jessie Bunker-Maxwell]

Jon, a backup that took 5 hours on the TZ88/DLT4000 now takes only 3 hours on the DLT8000 using the /block_size=65535 qualifier on the output. The first several attempts I made on the DLT8000 without the block_size switch resulted in a backup that took 12 hours, so this was a major improvement. I will still spend some time when I have it to try to determine if the SCSI card is playing any part in reducing throughput but I am satisfied with the performance we are getting now although it's not quite what I had expected based on a comparison of the performance specs for the two tape drives.

Jess

[Jon Pinkley]

Jess,

Thanks for the update.

From your original message starting this thread:

"Backups using the TZ-88 tape drive complete in about 6.5 hours."

From your latest message:

"a backup that took 5 hours on the TZ88/DLT4000 now takes only 3 hours on the DLT8000 using the /block_size=65535 qualifier on the output."

Where these backups of different things, or did the backup on the DLT4000 improve from 6.5 hours to 5 hours when you specified /block=65535?

Blocksize is low hanging fruit. To get more performance will require a bit more work. You have just moved from one limiting factor to another. If you are satisfied with the current performance, then it really may not be worth your time to investigate how much you can improve things. No matter what you do, you probably will not make your image backups go 4 times as fast on the DLT8000 as on the DLT4000, all other things being equal.

Jon

[Jessie Bunker-Maxwell]

Hi Jon - the difference in times is due to an additional change I made that's unrelated to throughput but has shortened the overall backup time - which is that I've removed the qualifier that writes the backup recording date on all files backed up. I didn't realize how much time that was adding to the complete backup job until recently and since we are doing image backups nightly and don't use the backup date as a selection parameter, it didn't make sense to continue it. The time saved is the difference between the 6 1/2 hours and the 5 hours.

Jess

[Jon Pinkley]

Jess,

Is this 1.5 hour difference for one disk, or for several? There must be a large number of files, and if they are relatively small, any file based (non-physical) backup will be relatively slow. That is the reason for asking how long the backups take to the NL: device, leaving everything else equal. If it takes two hours to backup to the NL: device, then backups to tape will take longer than that. Backup still processes files in directory order, so every file will involve seek times. In other words, there is overhead for every file open, and the more files involved, the more elapsed time will be spent.

A physical backup will probably come closer to the 4/1 transfer ratio of the DLT8000/DLT4000, but there are other factors that can add delays. The backup recording pass is a good example; the speed of the tape drive has absolutely no effect on the time it takes for the recording pass. Likewise, the speed of the tape drive has no effect on the time it take to read the date off the disk, compute CRC, set up the $QIOs, etc.

Jon