Here's a quick summary of the initial problem:
On a Sun Sparcstation 20, running SunOS 4.1.3_U1, there's a WangDAT
drive attached that is performing very slowly. Tape read/write is
slothlike, at best. The 'active' light blinks every couple seconds.
Reading/writing (using tar, cpio, dump) takes on the order of 3-4
minutes per meg. What can be done to speed up the performance of
this drive?
I received 3 messages and the one listed first was tried successfully.
Thanks to all who responded. This list is wonderful!
...Shirley Gruber
===================================================================================================
From: "Kevin A. Noll" <knoll@csl-emh2.army.mil>
To: sun-ask@netserver.stanford.edu
Subject: Re: WangDAT drive runs slowly
[question deleted]
Yes, wang knows very little about their own product, and Sun wont help you
either, they will say it should work as is, or it is an unsupported
product.
I have a set of Wang 3200 DAT's that I had the identical problem with.
You say that the drive is recognized at boot time?
It probably is recognized, but right afterwards (or right bfore) a message
of 'Unrecognized vendor' appears.
You have to modify the kernel files in /sys/scsi/targets.
You need the following in your st_conf.c file
---------- snip ------------- snip -----------------
/* WangDAT Model 3200 4mm Helical Scan 2GB drive */
/* Added by K. A. Noll 1 Jun 1994 */
{
"WangDAT Model 3200", 18, "WangDAT Model 3200",
ST_TYPE_WANGDAT, 1024,
(ST_VARIABLE | ST_BSF | ST_BSR | ST_LONG_ERASE),
5000, 5000,
{ 0x00, 0x8C, 0x8C, 0x8C },
{ 0, 0, 0, 0 }
},
------------------------------------------------------
This is basically a copy of the Archive Python entry w/ appropriate
changes.
You also need the following in the stdef.h file.
#define ST_TYPE_WANGDAT 0x2b /* WangDAT */
in the table with all the other 'ST_TYPE' entries.
The structure in st_conf.c is probably does NOT have the optimal settings,
but with my limited knowledge of how the drive works that is what I have,
and it works, speeding my backup rates to very close to what Wang says
it should be.
Try this. If it doesnt work, let me know and we'll do some more experiments.
--kan--
-- Kevin A. Noll, KD4WOZ kan@crc.com Electrical Engineer (407) 352-3700 vox Coleman Research Corporation Orlando, FL #define PWD "Carlisle Barracks, PA"=================================================================================================== Date: Wed, 28 Sep 94 13:59 MET From: martin@gea.hsr.it (Martin Achilli) Subject: Re: WangDAT drive runs slowly
Hello, we have a Wangdat 1300 here, we purchased it from a vendor called Gigatek in Italy. In its box we found all kinds of accessories to hhok it up to a Mac. Nevertheless, we hooked it up to our Sun, as the vendor told us to. The write performance was terrible. I think about 1-2Mb per minute, so I called the vendor. Apparently there are differences between Mac SCSI and traditional SCSI. He instructed me to flip a dip switch INSIDE the drive. After that the drive was about 8 TIMES faster. We have been using it that way since. Ask Wang for more info on the DIP switches, perhaps your problem is as simple as ours was.
Good luck,
Martin
P.S. do you have an active terminator on the SCSI bus ?
=================================================================================================== Subject: Re: WangDAT 2600 Date: Tue, 04 Oct 1994 08:47:58 +0930 From: Nick Jeitner <nmj@ICSEAAda.levels.unisa.edu.au>
Hi,
I've got a WangDAT 2600 and dont seem to have the same symptoms that you describe. But I have the configurations data that I've built into the kernel:
in /sys/scsi/targets/st_conf.c
/* * The following entries are local modification made by Nick * Jeitner, to support DAT drives used in CIS (UniSA) */ /* WangDAT Model 2600 3.81mm helical scan cartridge */ { "WangDat 4mm Helical Scan", 4, "WangDAT Model 2600", ST_TYPE_EXABYTE, 1024, (ST_VARIABLE | ST_BSF | ST_BSR | ST_LONG_ERASE | ST_AUTODEN_OVERRIDE ), 5000, 5000, {0x00, 0x13, 0x93, 0x00 }, { 0, 0, 0, 0 } },
Note: I did'nt change stdef.h or mtio.h because I just pretended that the drive was an EXABYTE (crucifixion?..... first on the left).
The following are the parameters I use for a network backup (using rdump):
density = 61000 (compression/compression jumper set as well!) length = 3700 (with 90m tape, not recommended) block factor = 512. ( theres been sum dicussion on sun-managers on the setting of the blocking factor and how it effects through put. If you cant find it let me know and I'll dig out a copy ). -------------------------------------------------------------------------- Nick Jeitner PH: +61 8 302 3033 Computer Systems Officer FAX: +61 8 302 3381 School of Computer & Info. Sci. E-mail: Nick.Jeitner@unisa.edu.au University of Sth Australia POST: CIS, Uni Sth Aust, The Levels, SA 5095
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:11 CDT