SUMMARY: HP35450A DAT & SUN SParcstn2 unacceptably slow;problem solved

From: Martin Wendel (martin@alba.udac.uu.se)
Date: Tue Sep 03 1991 - 02:16:41 CDT


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