Re discussion of tape comments

[Doug Hagerman, 508-841-2145, Flames to NL: 09-Jul-1996 1449]

* From the SCSI Reflector, posted by:
* "Doug Hagerman, 508-841-2145, Flames to NL:  09-Jul-1996 1449" <hagerman at starch.ENET.dec.com>
*
Hi Rod.

Thanks for taking the effort to look at this stuff.


> >  I'm assuming that the "large buffer" model is in effect. (That is,
>
>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.

This was what I proposed at the SSC meeting in May, and the tape
representatives present at that time were comfortable with it.

>
>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.

I agree with your analysis, but what we're talking about is full speed
Fibre Channel at 100 MBps. This gets you well up into the 90s.



>
>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.

The current proposal is that in a series of WRITE commands, the drive
accepts the data and returns the status to the initiator. Without errors
on the interconnect (hopefully the normal case), and with a fairly small
buffer, streaming can easily be maintained. (Note implicit assumption
that the round-trip time is small. Whether this works on world-wide
interconnects is not clear.) Start-stop cycles on the media are not
part of the goal.



>
>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?

The current proposal is that this doesn't happen because you never get
into the situation of being out on the media without having all the data
in hand. This was exactly the situation that triggered this whole discussion.

Perhaps the "large buffer" assumption needs to be tested more.

>
>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.

The current proposal is that tape don't support the SCSI queueing model
(although they could according to the standard). What they do is
accept commands and data into an input buffer and return a success status
when all the data is received. If an error occurs in trying to write
to the media, it's a deferred error. We haven't actually talked about
that yet, and yes I suspect it's a nightmare.

Keep those letters and cards coming!

Doug Hagerman
Digital Equipment