New thread for slow DLT8000.

[Rene Jasperse]

Hi,

A couple of months ago I posted a question about a DLT8000 runnin at half the normal speed.
Unfortunately I cannot find it back, so I will post a new one.
My hardware is a HP XW8000 with 2 3.06 GHz processors, 1 GB RAM and U160 SCSI-disks.
The OS is Windows XP Pro SP1 and I use veritas 8.6 including latest driver-update.
The system BIOS and SCSI-firmware is also updated.
I use the Veritas drivers; not the Microsofts.
The buffersize is changed to 64K.
The motherboard includes a LSI Logic 1020/1030 U320 LVD dual channel SCSI controller.
When the DLT8000 is connected to this controller it runs full speed (~300 MB/min) but errors occur when a tape must be changed (probably after rewind).
Connecting it to an Adaptec 2940UW the speed is about 190 MB/min
Next step was connecting the drive to the (internal) U160 domain of an Adaptec 19160; speed 150 MB/min.
Finally got hold of the real thing; an Adaptec 29160.
Still not faster than 150 MB/min.
The drive is the only device coupled to the 29160 on SCSI-ID 8 and is recognized to operate at 20 MB/s.
The cable length is less than 30 inches and the bus is terminated with an active LVD terminator.
I have changed cable and terminator and drive also.
For the record I like to state that a TL891 library connected to a LSI Logic 53C875/53876 HVD on the same PCI-bus does operate at full speed.
I will include the support ticket I made today.

Thanks again for any help,
Rene.

[Allan_24]

Hi,

Have you tried this technote before?

1.(What VERITAS Backup Exec (tm) settings can be modified to reduce the amount of time it takes for a backup to run)

http://seer.support.veritas.com/docs/249090.htm

2.(Reasons why the data throughput rate can be slower than the theoretical maximum when backing up to tape media)

http://seer.support.veritas.com/docs/231488.htm

Hope this helps,

[Rene Jasperse]

Allan,

Unfortunately I tried almost all of the suggestions in those documents.
The SCSI comm. is oke; changing veritas settings like buffersize does not help.
Changing other settings like progress indication makes no difference, which is likely.
The machine is a dual 3.06 GHz processor, 533 MHz FSB, Dual channel U320 SCSI controller, U160 10K rpm SCSI-disks, support for the latest PCI-X slots â ¦. So system performance simply cannot be an issue.
I have already exchanged the drive, the cabling, termination, several controllers (2940/19160/29160 slow without errors and LSI 1020/1030 fast with errors) and the tape-media.
Now I am hoping the support ticket will reveal the nature of the problem.
If all fails, I will restore the system (after ghosting the OS) to the restore-CD and reinstall all programs.
I will also try to install the 29160 with the drive to another HP computer and see at what speed it operates.
Thanks anyway for your input.
Ren

[Brice_5]

> When the DLT8000 is connected to this controller it runs full speed (~300 MB/min) but errors occur when a tape must be changed (probably after rewind).

Is on board LSI controller a RAID controller?

> The drive is the only device coupled to the 29160 on SCSI-ID 8 and is recognized to operate at 20 MB/s.

DLT8000 is wide device (16bits) and capable of handling 160MB/s rate. 20 MB/s might be the bottleneck. So enable "Wide Negotiation" and bring the speed back to 160 MB/s.

[David Ruska]

> DLT8000 is wide device (16bits) and capable of handling 160MB/s rate.
> 20 MB/s might be the bottleneck.
> So enable "Wide Negotiation" and bring the speed back to 160 MB/s.

This is incorrect. Ultra160 SCSI didn't even exist when the DLT8K drive came out.

Here's Quantum's data sheet:
http://www.quantum.com/NR/rdonlyres/7225D7FE-D6EF-4387-B865-FC4A77992E06/0/DLT8000DS618.pdf

They say it is SCSI-2 Fast/Wide, and has a burst rate of 20MB/Sec.

[David Ruska]

> When the DLT8000 is connected to this controller it runs full speed (~300 MB/min) but errors occur when a tape must be changed (probably after rewind).

Collect the system event logs and a support ticket from the drive using HP Library & Tape Tools (www.hp.com/support/tapetools).

We can then figure out what is causing the error.

> Connecting to Adaptec 2940UW the speed ... 190 MB/min
> connecting to .. 19160; speed 150 MB/min.
> Finally ... an Adadtec 29160. Still not faster than 150 MB/min.

If you have a good data source, and are using a block size of 64K, you should be able to get 6 to 12 MB/sec (depending on compressability of data).

Your 300MB/Min is 5MB/sec. There's no reason you shouldn't be able to get 300MB/min or better.

When you install LTT, you can use the dev perf (performance) test to verify your drive can go 6 to 12 MB/sec.

If it doesn't I think it could be drive error rate. The way to check that would be to pull a support ticket after a backup (before the tape is unloaded), and look at the write error counters.

[Rene Jasperse]

David,

I finally made a support-ticket while the DLT was connected to the on-board (LSI-logic 15C1030) controller.
The back-up procedure ended before changing to the third tape.
I cancelled the Veritas 8.6 job without removing the tape.
The tapes used are original HP brand-new; Only used once before in this drive.
The back-up speed was around 290 MB/min.
I hope you can see in the ticket what the cause is.
As I mentioned earlier, this error occurs randomly.
Next I will send a support-ticket of a back-up while the drive is connected to the Adaptec 29160.
LTT reports a tape-speed of 2.7 - 4.4 MB/min in this situation.

Rene.

[David Ruska]

Rene,

DLT drives have this habit of not wanting to show you anything useful in their logs. Here is the information in the device analysis section of interest:
----
Drive power on hours: 3065
Tape pulling hours: 239
Last Media ID: 101546 (0x18caa)
Cleaning Cycle Count: 4
Compression data:
There was insufficient data transferred to calculate read compression ratio.
There was insufficient data transferred to calculate write compression ratio.
corrected read errors: 0
corrected write errors: 0
----
You have very low tape motion hours, so that head should be like new.

All the compression ratio information (and the write and read counters) are cleared out. I suspect that the app sent an unload command which immediately clears all the counters (unfortunately).

Looking at the drive error logs, there were only a few tape calibration errors and those are old, there are no cleaning lights and no write or read errors. I don't think the drive is having error rate problems.

You mentioned:
> LTT reports a tape-speed of 2.7 - 4.4 MB/min in this situation.

Is that with 2:1 compression data and the default block size? You should be able to get close to 12MB/sec.

The configuration data says compression is enabled.

Can you run the devperf test again and collect a support ticket afterward? Something isn't right.

I noticed you have a number of HBAs in your system. I wonder if there's an issue with transferring data between the system and the HBA. Have you checked the HBA bios settings(i.e. wide negotiation enabled, sync negotiation enabled, etc)?

[David Ruska]

Rene,

I reviewed your first support ticket, and noticed a few things. Here are some extracts (you can view the .ltt file and see where these are yourself):

---
* Drive Configuration Settings
Buffered Mode : 1
Data Compression : Disabled
...
* Drive Error Statistics
Read errors corrected w/substantial delays : 0
Total read rewrites or rereads : 2
Total read errors corrected : 2
Total read bytes processed : 0x000000000FCF7B00
Total read uncorrected errors : 0
Write errors corrected w/substantial delays : 0
Total write rewrites or rereads : 183
Total write errors corrected : 183
Total write bytes processed : 0x000000000FCCF6A0
Total write uncorrected errors : 0
---

First off, write buffering was enabled (1), which is good. However, compression was disabled (was that intended)?

More importantly is the corrected errors and total bytes (in hex). You can use this web page:
http://www.ronshardwebapps.com/Numbers.asp#marker

and find the number of bytes written was 265MB, and there were 183 corrected errors.

That 0.7 errors/MB. From some performance testing I've done in the past, that rate cuts the performance almost in 1/2. So for this data with compression off, you would have had 3MB/sec (or 180MB/min).

One guess is your drive is sensitive to certain manufacturers of media. You could use the performance test and the view the support ticket to see which tapes have the most corrected errors/MB. Then look to see what is common about the tapes. Every DLT tape has a mfg serial number on the hub side of the tape. Each manufacturer has a different letter digit in the middle of the serial number.

Another possibility is you have some contamination or staining on the head causing fluctuations in error rate. Find a tape with the highest error count, then run a NEW dlt cleaning tape 3 times in a row. You want to use a new tape, as a used one might have contamination on it.
After doing the cleaning, rerun the test a few times. The reason you need to do it a few times is the act of cleaning can actually leave some loose debris on the head which will get cleaned off after running 10 to 20 minutes of normal tape over the head. Check the final numbers, and see if they got better from the initial test (before cleaning).

The drive logs indicate you have only cleaned 4 times (which is fine - DLT drives don't normally need periodic cleaning).

So, that's my best guess at the moment.

[Rene Jasperse]

David,

Some more test results.
First when the drive is connected to the LSI controller.
The settings are as follows.
SCSI-id=8, MB/sec=320, MT/sec=160, Datawith=16, Scanid=Yes, Scanluns=Yes, Disconnect=ON, SCSItimeout=10msec, Queuetags=ON, Bootchoice=NO.
The results of the LTT drive-performance test is that the drive reads and writes at about 9 â 12 MB/s.
The last support ticket said that compression is OFF, but the according light on the drive is ON.
In Veritas the compression is also enabled.
The ticket also contains an error message A40D (Directory write fail (Retries exceeded) After Unload).
This must be the error causing the job to stop.
Next I reconnected the drive to the 29160.
It is still recognized at 20 Mb/s, which is sufficient.
I ran the Device Performance test with the LTT.
I selected a zeros and a 2:1 compression test.
Both resulted in a 2 MB/s performance, which is extremely slow.
I didnâ t select the rate limit there
I add the ticket after both tests for you to examine.
In the mean time I have completely run out of ideas but to completely reinstall all software.
All other changes make no difference.
Oh, I think of one just now.
That is connecting one of the disks to the 29160 and see if performance (copying a large file) is not slower (the disks are U160).
I will disconnect the DLT because it can cause problems.
Still .. any help is highly appreciated.