DAT Performance / Throughput

[Wes Wilkey]

I have a Compaq 12/24 autoloader (TSL-9000) connected to an Adaptec 2940U2W controller on a Windows 2000 Server. I'm using Backup Exec 8.5. I ran a suite of tests on throughput (see results below). No matter what settings I use for the drive, I get no substantive change in throughput. Additionally it is very slow, at only 21.2 mbpm all the while my CPU utilization is only 5% and the disks are barely being touched. How can I crank up the
throughput on this drive?

Thanks,

Wes


===========================================================
Test 1: 8k, 32, 10, 0 (Default)

Backed up 112 files in 10 directories.
Processed 110,174,973 bytes in 4 minutes and 57 seconds.
Throughput rate: 21.2 MB/min

===========================================================
Test 2: 32, 32, 10, 0

Backed up 112 files in 10 directories.
Processed 110,174,973 bytes in 4 minutes and 57 seconds.
Throughput rate: 21.2 MB/min

===========================================================
Test 3: 32, 32, 20, 15

Backed up 112 files in 10 directories.
Processed 110,174,973 bytes in 4 minutes and 57 seconds.
Throughput rate: 21.2 MB/min

===========================================================
Test 4: 32, 1024, 20, 15

Backed up 112 files in 10 directories.
Processed 110,174,973 bytes in 4 minutes and 59 seconds.
Throughput rate: 21.1 MB/min

===========================================================
Test 5: 16, 32, 10, 0

Backed up 112 files in 10 directories.
Processed 110,174,973 bytes in 4 minutes and 56 seconds.
Throughput rate: 21.3 MB/min

===========================================================
Test 6: 4, 32, 10,0

Backed up 112 files in 10 directories.
Processed 110,174,973 bytes in 4 minutes and 58 seconds.
Throughput rate: 21.2 MB/min

===========================================================

[Brian M Rawlings]

Hi. Check the block size, I believe Backup Exec defaults to 1k, change to 32k for better performance. Other possibilities exist too, like network speed (10Mbps can be slow), etc. Presuming you are backing up internal drives to a locally attached DAT12 (DDS3), with DDS3 120 meter tape media, you should be able to get 1-1.5 megabytes per second or so, more with compression (which varies with data types).

Regards, --bmr

[Brian M Rawlings]

Sorry, I didn't notice the block size changing on your tests, so you've thought of that.

Given that all the blocking factors (etc) perform identically at the tape drive, it looks like the DAT unit is not your bottleneck. What are you backing up?

One old, slow IDE drive might not be able to deliver data any faster, for instance. I can't imagine a SCSI drive that couldn't push this faster than 21Mbpm, but a severely fragmented drive might be this slow.

If you had to do any manual BIOS setup for the internal disk(s), you may need to check settings for large block transfers and things like that (smart disk features can hobble performance if set wrong).

To double-check that the issue isn't in your DAT drive/changer, move it to a different, faster host, if you can. Your performance should be different, but should peak out between 60Mbpm and 100Mbpm if the disk is fast enough to keep the DAT streaming. This would indicate that the DAT is maxing out, rather than having data rationed to it by a slow drive or system.

Regards, --bmr

[Glenn Weavind_1 · Accepted solution]

Might be worth checking the backup performance with a new tape after cleaning. Because DAT (like DLT) does automatic, drive controlled read-after-write verification, lots of bad blocks can cause poor throughput (I've actually seen this) as the drive re-writes bad blocks on another stripe, and stops accepting more data from the host.
PMFA but you are using DDS3 media?
Also, is the DAT drive on the same SCSI bus as the HDDs - because if it is that may be the cause. From memory the DAT interface is ultra, but narrow, and will force the entire SCSI bus off Ultra2 speed, and hog most of the bandwidth so preventing the HDDs (U2W) from transferring data at their, very much faster, rate.

[Wes Wilkey]

To clarify the configuration issues you've mentioned:
- This is a backup of local drives.
- The drives are IDE UDMA/33s and have very little disk activity during the backup. I'd expect them to be thrashing.
- This drive is a new replacement for an old HP DDS2 drive I had on the SCSI bus. That drive got 40mbs compared to this one at 22mbs.
- The drives are defragmented nightly, so not issue there
- The only devices on the SCSI controller are this drive and a plextor 2x CDROM
- I haven't tried it with a new tape, but the current backups are showing few soft errors and no hard errors.

Thoughts?

[Vincent Fleming]

Hmm...

Is the tape drive the only thing you changed?

If it's not the only thing you changed, then I think you need to narrow down where the problem might be... can you tell us exactly what you changed?

Try putting the old drive back and testing it again. The outcome of this test could be enlightening.

-Vince

[Wes Wilkey]

Can't put the old drive back, it's dead. The heads are junk.

Yes, it is the ONLY thing I changed.

[Glenn Weavind_1]

Wes: It looks as the the fundamental problem is the DAT drive not accepting data at a reasonable rate. Possible causes a) your drive really doesn't like your old DDS2 media: try a brand new DDS2/3 tape b) SCSI bus issues - perhaps old drive was self terminating/ new drive isn't (or not set to be) c) new drive has option DIP switches set incorrectly/differently to old drive (e.g. read-after-write verification.
If above yields nothing I would a) move new DAT drive to another machine, and assess throughput there b) check for SCSI driver updates (DDS3 device may have uncovered bug in existing SCSI driver).

[Wes Wilkey]

Thanks to all who have helped out on this. At present it seems the root of my performance is in the media. I had been using NEW DDS2 media as that's what I had. I put in a new DDS3 tape and my throughput jumped from ~22mbps to ~100 mbps. I'm amazed that writing to the older format requires so much overhead...

Any thoughts on why this happens?

Thanks again to all!

Wes