TK50 / TK70 Media Differences

[Paul Koning]

>>>>> "Jerome" == Jerome H Fine <jhfinexgs2 at compsys.to> writes:

 >> Paul Koning wrote:
 Jerome> As for being faster, the TQK70 / TK70 almost certainly has
 Jerome> the ability to buffer records internally and do a read of the
 Jerome> next record. ...
 >> That would make sense.  I think a (T)MSCP controller is likely to
 >> be buffered anyway.  My comment on speed and bus bandwidth relates
 >> to continuous running speed -- if a tape when in full speed
 >> streaming mode produces more data than the bus can handle, you'll
 >> overrun whatever buffers the controller may have (sooner or later)
 >> and streaming will stop.  So tapes like the TK series require a
 >> bus that's comfortably faster than the drive, or their performance
 >> will be atrocious.  (Your TK50 verify experience is an example --
 >> which shows that performance also critically depends on correctly
 >> designed software.  It's a bit of a surprise that RT11 would get
 >> this wrong, since getting it right is very easy in RT11.)
 >> 
 >> 
 Jerome> Jerome Fine replies:

 Jerome> The aspect that I think is not being considered is that the
 Jerome> comparison between the ( TQK50 / TK50 ) and the ( TQK70 /
 Jerome> TK70 ) was run using the IDENTICAL program (BUP.SAV) running
 Jerome> under RT-11.

 Jerome> Since the verify program runs efficiently only with the TK70
 Jerome> drive, it seem to be the hardware which makes the difference
 Jerome> - or at least the firmware on the TQK70 controller - which is
 Jerome> outside the software for both RT-11 and the BUP.SAV
 Jerome> application program.  Again, I can only conclude that the (
 Jerome> TQK70 / TK70 ) keeps the streaming tape reads of the TK70 in
 Jerome> operation by starting the next read of the next record on the
 Jerome> tape without being asked to do so by either RT-11 or the
 Jerome> BUP.SAV program.

Sure.  But the point is that a tape processing program that intends to
support streaming tape drives MUST issue several I/Os concurrently.
That was my point.

Case in point: RSTS BACKUP does both backup and verify without any
problem on streaming tape drives, including the TK50.  The reason is
that it keeps a bunch of writes or reads outstanding, so the
controller always has work for the tape and the tape never has to
stop.  Adding that to RSTS required significant surgery.  But RT11 and
RSX, being real-time operating systems, always have had async I/O
requests (.read and .reada in RT), and by using those it's very easy
to keep a tape streaming both in write and in read mode.

   paul