I would like to thank everyone who answered my posting regarding HP35450A DAT
and SUN Sparcstation2. The answers were very helpful and I have been able to 
fix the Sparc into high level performance (150kB/s and more). These answers
could also be useful to others so I'll include a summary here.
>From Kevin Jones:
>The problem you are seeing is due to the fact that the SPARCII is
>not recognising the HP drive and is defaulting it to "unbuffered mode".
>This means that the drive is flushing data from the buffer to tape for
>each SCSI command, resulting in appalling performance.
>From Eric A. Pearce:
>Before you condemn the drive, try doing a "mt" status on the device.
>Does it recognize it as a Helical Scan device or a QIC-150 tape drive?
>The driver defaults to QIC-150 if it doesn't recognize the returned
>vendor string when it first probes the device.   This might affect
>performance and the types of operations supported on it.   This
>is pretty easy to fix if you are using the stock 4.1.1 st driver.
I tried the above ("mt -f /dev/rst1 status") and before the sparc was 
correctly fixed the mt command would output "EXABYTE..." +more, and after
the fix "SCSI device..."+more. I would explain this as when the SUN doesn't
recognise the drive mt will guess at something in the mt tables. When the
drive is recognised mt will just reply that SCSI recognition succeded and
it's a SCSI device (not specifying what vendor).
>From John Posey:
>The HP35450A will live up to its specifications if you apply the
>following patches to /sys/scsi/targets/st_conf.c and
>/sys/scsi/targets/stdef.h, rebuild your kernel, and reboot.  Note that
>the 10240 value is 512 * 20, but could be increased up to the drive's
>5K buffer size.  Hope you still have the drive to test this on...
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
*** st_conf.c.orig	Sat Aug 31 12:10:23 1991
--- st_conf.c	Sat Aug 31 12:10:23 1991
***************
*** 119,138 ****
--- 119,147 ----
          { 0x01, 0x02, 0x03, 0xC3},
          {  0, 0, 0, 0 }
  },
  /*
   * The drives below have not been qualified, and are
   * not supported by Sun Microsystems. However, many
   * customers have stated a strong desire for them,
   * so our best guess as to their capabilities is
   * included herein.
   */
+ /* HP DAT 4mm cartridge */
+ {
+ 	"HP DAT", 24, "HP      HP35450A      -A", 
+ 	ST_TYPE_HPDAT, 10240,
+ 	(ST_VARIABLE | ST_BSF | ST_BSR | ST_LONG_ERASE | ST_AUTODEN_OVERRIDE),
+ 	5000, 5000,
+ 	{ 0x00, 0x00, 0x00, 0x00 },
+ 	{  0, 0, 0, 0 }
+ },
  /* Exabyte 8mm cartridge */
  {
          "Exabyte 8mm Helical Scan", 7, "EXABYTE", ST_TYPE_EXABYTE, 1024,
          (ST_VARIABLE | ST_BSF | ST_BSR | ST_LONG_ERASE | ST_AUTODEN_OVERRIDE),
          5000, 5000,
          { 0x00, 0x00, 0x00, 0x00 },
          {  0, 0, 0, 0 }
  },
  /* Wangtek QIC-150 1/4" cartridge */ {
          "Wangtek QIC-150", 14, "WANGTEK 5150ES", ST_TYPE_WANGTEK, 512,
***************
*** 171,185 ****
--- 180,195 ----
          /*
           * This is in non-buffered mode because it doesn't flush the
           * buffer at end of tape writes. If you don't care about end
           * of tape conditions (e.g., you use dump(8) which cannot
           * handle end-of-tape anyhow), take out the ST_NOBUF.
           */
          (ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR | ST_NOBUF),
          500, 500,
          { 0x01, 0x02, 0x06, 0x06},
          { 0, 0, 0, 0 }
+ 
  }
  };
  int st_ndrivetypes = (sizeof (st_drivetypes)/sizeof (st_drivetypes[0]));
  
  #endif	/* NST > 0 */
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
*** stdef.h.orig	Sat Aug 31 12:10:31 1991
--- stdef.h	Sat Aug 31 12:10:31 1991
***************
*** 40,59 ****
--- 40,60 ----
  #define	ST_TYPE_WANGTEK		0x16	/* Wangtek QIC-150 */
  
  #define	ST_TYPE_CDC		0x20	/* CDC - (not tested) */
  #define	ST_TYPE_FUJI		0x21	/* Fujitsu - (not tested) */
  #define	ST_TYPE_KENNEDY		0x22	/* Kennedy */
  #define	ST_TYPE_HP		0x23	/* HP */
  #define	ST_TYPE_HIC		0x26	/* Generic 1/2" Cartridge */
  #define	ST_TYPE_REEL		0x27	/* Generic 1/2" Reel Tape */
  
  #define	ST_TYPE_EXABYTE		0x28	/* Exabyte */
+ #define	ST_TYPE_HPDAT		0x29	/* HP DAT */
  
  
  /* Defines for supported drive options */
  #define	ST_VARIABLE		0x001	/* supports variable length I/O */
  #define	ST_QIC			0x002	/* QIC tape drive */
  #define	ST_REEL			0x004	/* 1/2-inch reel tape drive */
  #define	ST_BSF			0x008	/* Supports backspace file */
  #define	ST_BSR			0x010	/* Supports backspace record */
  #define	ST_LONG_ERASE		0x020	/* Long Erase option */
  #define	ST_AUTODEN_OVERRIDE	0x040	/* Auto-Density override flag */
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
This fix worked. Thankyou John! I've now gotten a transfer rate of over
170kilobytes per second in tests.
Kevin Jones also gave me a fix which I'm sure will work, it was just about 
the same as John Posey's.
I also got a fix from HP that was published in some kind of newsletter
but it didn't work. This really discouraged me. Afterwards, when comparing
the fixes I've got, I realise that HP had a faulty vendor string in their 
fix!?
-- 
______________________________________________________________ 
E-Mail:Martin.Wendel@UDAC.UU.SE ; Snail-Mail: UDAC
       Domainmaster@UU.SE                     Martin Wendel
       Postmaster@UU.SE                       Box 174
Tel:  018 - 18 77 80                          S-751 04 Uppsala
Int: +46 18 18 77 80                          SWEDEN
______________________________________________________________
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:19 CDT