29 Apr
2005
29 Apr
'05
7:32 a.m.
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 Fine replies:
The aspect that I think is not being considered is that the comparison
between the ( TQK50 / TK50 ) and the ( TQK70 / TK70 ) was
run using the IDENTICAL program (BUP.SAV) running under RT-11.
Since the verify program runs efficiently only with the TK70 drive, it
seem to be the hardware which makes the difference - or at least the
firmware on the TQK70 controller - which is outside the software
for both RT-11 and the BUP.SAV application program. Again, I
can only conclude that the ( TQK70 / TK70 ) keeps the streaming
tape reads of the TK70 in operation by starting the next read of the
next record on the tape without being asked to do so by either RT-11
or the BUP.SAV program.
If I were to make a guess, it might be possible to verify this by the
use of a test program. Perhaps 10 tape records could be read
after which the test program would idle until the tape movement
of the TK70 stooped. Then the test program would read 1 more
tape record and the user could manually observe if there was any
tape movement. If YES, especially if there was first a backward
motion followed by a forward motion, I would conclude that the
TQK70 had scrapped the extra record read - if that was ever the
actual situation. BUT, if NO (no additional tape movement), then
the TQK70 had obviously stored and saved within a hardware
buffer on the TQK70 the eleventh (next) 8192 byte record.
Further tests and timing might be able to establish just how long
the test program can wait to issue the next read of the next tape
record (after the current tape record has been received) before
streaming motion is lost on the TK70. The basic timing information
is that 32 MBytes are written in about 7 minutes using 8192 byte
records - if my math is correct, about 100 records per second.
So a delay of even 1 millisecond between each read of each
record would quickly become too much of a delay. I am not
sure where this paragraph is leading, just a few thoughts being
written down at this point.
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.