29 Apr
2005
29 Apr
'05
8:03 a.m.
>>>> "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