SUMMARY: Poor DAT performance

From: Jared Rhine (jared@osiris.ac.hmc.edu)
Date: Wed Sep 08 1993 - 01:49:35 CDT


The correct response came from Tim Perala. Worked beautifully with no
problems. My first dump of 150 Mb averages 19.3 Mb/min.

Original question:

Our site recently purchased a DAT drive for normal backup of our main
server. Touching /reconfigure created the device drivers as expected,
and the tape works for simple tasks. However, performance is abysmal.
Using a TAPES environment variable of /dev/rmt/0cn, which should
enable compression, a backup performed with 'dump' of approximately
700 Megs took an estimated 14 hours, although the backup did not
actually finish; it asked for a second volume. The dump logs indicate
a 32K blocking factor is being used. Remote dumps seem to work fine,
to the speed limit of Ethernet.
 
The drive is from r-squared and is the same used in the HP 35480A SCSI
DAT drive. We are running Solaris 2.2 on a Sparcstation 10/512.

The correct response came from Tim Perala. Worked beautifully with no
problems. My first dump of 150 Mb averages 19.3 Mb/min.

From: Tim Perala <tperala@ua.d.umn.edu>

YES!!

If it is the same problem the fix is...

Disassemble the box to get access to the bank of 8 dip switches
on the belly-side of the tape drive. The switch setting that
worked for us (and was given to us by UNIDATA, a reseller) is

      1 2 3 4 5 6 7 8
      1 1 1 1 1 0 0 0

Let me know if this works for you. Good luck.

Other responses:

From: larry@ma.pdc.com (Larry Freeman)

Normal 'Dump' performance should be 300 - 350 kb/sec when backing up local
file systems (18 - 21 MB/minute). You didn't say what the performance was
if you backed-up in non-compressed mode. Remember that the 2.x DAT commands
are in support of the Archive Python DAT (the one that Sun is selling) and
not the HP DAT drive; lord knows what mode the HP is really writing.

The other strange phenomenum is that you are hitting the end of tape. This
almost sounds as if the DAT drive is doing an inordinate number of write
retries. Check the `messages` file or its 2.x equivalent to see if the OS
is complaining about any hardware retries.

From: Ted Rodriguez-Bell <ted@ssl.Berkeley.EDU>

The problem could be inside the drive housing. I have a WangDAT
drive (as it happens, from R-Squared) that used to behave like this.
There's a jumper setting on the drive that allows you to set the
maximum transfer size. Changing this from 8K to 32K did wonders for
our performance. I found out about this by calling R-Squared and
asking what was wrong; they suggested this fix and sent me a copy of
the manual for the tape drive.

The second volume message means that you gave dump the wrong arguments
for tape size. Size, density, and number of tracks are dummy
arguments that dump uses to calculate the capacity of the tape. Dump
can't handle an EOT message from the tape drive, so it tries not to
exceed the tape's capacity. Just raise one of those parameters until
you can put your entire drive on the tape.

From: Martin Achilli <ACHILLM%IMIHSRA.BITNET@vm.cnuce.cnr.it>

Hello,

a while ago we purchased a PROCOM TECHNOLOGIES 2 Gb Dat drive
from a firm here in Italy. When the drive arrived, it came with
Macintosh and Sun SCSI cables, with a back up program called
RETROSPECT for the Macintosh and a backup program for the IBM
 PC.
I was told to connect the drive to the SCSI chain of one of our SS2
(which is r unning 4.1.3). The performance was very poor, averaging
about 200 Kb per minute during backups . I phoned the supplier and he
told me the drive had been set up for a Macintosh (there are small
differences between Macintosh SCSI and Sun SCSI). So he instru cted me
to open the drive, move a dip switch and close it again. The
performance jumped to about 8 Mb per minute, a 669Mb drive takes about
1 ho ur and a quarter to back up. You also need to specify a
different blocking factor than 150Mb cartridge tapes , so check that
out with R-squared.

From: hkatz@NUCMED.MED.NYU.EDU (Henry Katz)

Sounds like your kernel is incorrectly configured. I don't know sol 2.x
yet but in 4.3 you should check the st_conf.{c,h} files for the correct
params for your DAT. If the kernel doesn't make the match it defaults
to a QIC which is slow as shit. Call up r^2 and ask the tech people there.

============================================================================
Jared Rhine | "Remember, only users lose drugs"
Jared_Rhine@hmc.edu |--------------------------------------------
wibstr - Harvey Mudd College | "To live is to war with trolls."



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:09 CDT