some comments on PLDA tapes using Class 3

[Charles Monia 237-6757]

* From the SCSI Reflector, posted by:
* Charles Monia 237-6757 <monia at AM.SHRMSG.SHR.mts.dec.com>
*
Hi Rodney:

I believe the "size of tape buffer" parameter represents the largest write
command that is guaranteed to have the properties described in Doug's note. ie.
As long as the amount of data to be written is equal to or less than this
number, a write command failure due to a transport fault will not result in a
partially written record.

This requirement says nothing about the actual amount of buffer space that's
available. I'd imagine that the drive would actually have much more "write
behind" buffering to sustain streaming.

Comments?

Charles

Rodney Van Meter wrote:
>
>   Also note that I'm not a tape expert ("Doug, you obviously don't
>   know anything about tape drives!"--Ralph Weber.), and I encourage
>   anyone who IS such an expert to review and comment on this subject.
>
>I'll second this (I'm no tape expert, either, but implemented the
>device controller for a high-speed magneto-optical disk drive) but I
>think my comments are relevant.
>
>   I'm assuming that the "large buffer" model is in effect. (That is,
>   every tape drive guarantees to provide at least 1 MByte of input
>   buffer space, or alternatively, a mechanism is defined for
>   negotiating the size of said buffer. Also, every SCSI READ or WRITE
>   command is guaranteed to specify less than 1 MByte (or the
>   negotiated amount) of data.) Using these rules, all the
>   interconnect-related activity can be completed before any tape
>   media activity is started.
>
>I can't quite tell if you're suggesting this to simplify the
>discussion, or if you believe it's a practical approach. I'm assuming
>the latter.
>
>Barring an infinite-speed interconnect (where "infinite" is a relative
>term :-), it's unrealistic to expect the drive to wait until all
>interconnect activity is complete before beginning to write the tape.
>It just throws away too much performance. Minimally, if the drive is X
>MB/sec and the interconnect is Y MB/sec., you're limiting yourself,
>optimistically, to Y/(X+Y) of the drive's performance. Give than
>current high-end drive/interconnect systems are working with Y/X
>ratios of 1.3 (Ampex DST w/ FW SCSI) to 8 (Sony DTF w/ HiPPI), you're
>talking about reducing performance to, respectively, 56% or 89% of
>max. The latter may be acceptable, the former certainly is not.
>
>However, as anybody who's dealt with real peripherals (I assume that's
>most of the readers here, including yourself) can tell you, the story
>doesn't end there. There is undoubtedly a device-specific threshold
>below which streaming can't be sustained. Then every command will
>result in a tape drive stall, costing ?10s-100s? of milliseconds while
>the tape motion is restarted. Hard on the mechanics and hell on your
>transfer rate.
>
>So, there's at least one more realistic case:
>
>   case                    what the          result of         next
>			   initiator         READ POSITION     initiator
>			   sees              command           action
>   =====================================================================
>
>   6. Failure in mid-	   command           result is	       ???
>   write, and status	   times out         MIDWAY between
>   gets lost on the way			     OLD and EXPECTED
>   back to initiator			     positions
>
>The action to be taken may be application-specific; rewrite where you
>are and go on? Rewind and try again?
>
>Note, too, that this is going to be complicated by the write caching
>policy and "deferred errors" (a nightmarish concept altogether; I
>don't know if it's retained in SCSI-3), and by the command queueing
>state at the device, too.
>
>Our approach on the Netstation research project
>(<http://www.isi.edu/netstation/>, but undergoing revision this week,
>so don't be surprised if you have trouble with it) is to assume a
>reliable transport mechanism (TCP or our custom DTP protocol)
>underneath, although we've had some discussions about relaxing that
>restriction. We're still months away (at best) from playing with
>anything more complicated (physically and in error recovery) than a
>hard disk drive with a SCSI interface, though.
>
>Hope this isn't too much of a rathole,
>

********************************************************************
* Charles Monia Storage Architecture Group                         *
* Digital Equipment, Shrewsbury MA   Internet: monia at shr.dec.com   *
* Tel: (508) 841-6757    X400: c=US; a=MCI; o=Digital; ou=SHR      *
* Fax: (508) 841-6100                                              *
********************************************************************