wyatt@cfa.harvard.EDU (Bill Wyatt) (06/17/88)
I've been mailing this summary, but the number of requests is starting
to increase, so I've decided to post.
Please note that this same controller/drive subsystem is reviewed in
the June 6th Digital Review. That review is more oriented towards
VMS, and was quite favorable. I've added a few extra annotations in
brackets that weren't in the original.
-------------------------------------
I have been testing the 8mm Exabyte drive coupled to a TD Systems
Viking QTO controller. This controller is a SCSI-to-TMSCP adapter, and
can control up to four interfaces. The local distributor for this
subsystem is Northeast Peripherals [Norwood, MA]. The system I'm
testing on is a Vaxstation II/GPX running Ultrix 2.0.
We are now on PROM rev. level 3.1, which seems to operate correctly
under Ultrix (unlike earlier revisions). These PROMs are supposed to
also write in the proposed `ANSI standard' format, which should allow
reading tapes written by other types of controllers adhering to the
standard. Northeast also markets a Ciprico controller for Suns that
should be compatible. Bim Toth [another systems programmer here at the
Smithsonian Astrophysical Observatory - SAO] has such a system, but we
have not yet been able to make a valid test. [N.B.: The
interchangeability remains our largest concern, and it hasn't been
resolved yet one way or the other.]
As to performance, the maximum sustained rate is 246 kbytes/sec, but a
number of factors can degrade this. Foremost is the tape positioning
time. It takes the unit about 30 seconds to start up, get the tape
positioned, and start moving. If the tape is at its beginning, it
takes several seconds longer to load and position. N.B.: VMS mileages
may differ. Upon closing a file after writing, it takes another 20
seconds or so to write the double tape mark and backspace over the
second of them.
In addition, while skipping over a file is relatively fast (about 40
seconds to skip a 100 Mbyte file), skipping the tape mark is
relatively slow. It takes about 6 seconds to skip a tape mark, which
probably reflects the positioning required to pick up the next data
track after the mark. Since each tape mark (in the long mark format)
is the equivalent of 2 Mbytes of data, some time is spent simply
moving past the mark, also.
Timing actual disk backups proved to be limited by disk I/O and/or CPU
throughput, so I measured the sustained throughput possible as a
function of the tape blocking size by timing the writing of records of
predetermined size as fast as possible (multiple-buffered and straight
out of memory), and subtracting the time to write a file containing a
single record. The following are the results:
Record size kbytes/sec
512 75
1024 135
2048 225
2880 220
4096 225
8192 225
10240 233
16384 240
32767 240
65536 240
Since the physical tape format is 1024 bytes/block, and 8192
bytes/track, it is not surprising that a small block size of 512 bytes
is slow. Somewhat more surprising, however, is that the throughput
increases when using blocks greater than 8192. Perhaps this reflects
some internal SCSI bus transfer overhead.
I investigated the Exabyte's throughput at disk- or CPU-limited rates
lower than its maximum. The Exabyte tape drive has a 256K buffer, and
does not load the head to write that data out until the buffer is
mostly full (or perhaps entirely full, I'm not sure). When the drive
sits idle for more than a few seconds, the head disengages from the
tape to prevent wear, but then takes longer, of course, to reengage to
write out the data.
The question is: is there a data rate slow enough to cause the head to
disengage, but fast enough to cause a program to wait for the buffer
to empty to tape? The answer appears to be a qualified yes: the 256K
buffer might be usefully increased in size. I simulated various data
rates by writing a block of some size, then sleeping for a second, and
repeating.
At rates somewhere above 16K bytes/sec, the head never disengaged,
although it can be heard repositioning itself, while at lower rates
the buffering allowed the head to reengage in time to sustain the
average rate. For rates of about 16 kbytes/sec and lower, then, the
buffering is fine.
The problem is that a slowdown effect occurs at rates of 32 Kbytes/sec
and above. While the effect is slight at that rate (about a 10%
slowdown), it is fairly severe at 128 Kbytes/sec (about a 30%
slowdown). Apparently, the tape is repositioning itself a little too
much to sustain the average rate, even though the head is not
disengaging. Of course, a low transfer rate followed by a sudden surge
in disk transfers (as, for example, when a large contiguous file is
encountered) might also cause a slowdown due to the head reengaging
the tape. [ I should note here that this test program made no attempt
to internally buffer the data, which might alleviate the slowdown. ]
Finally, I checked the capacity of the tape by writing 32768-word
records until an EOT error occured. For the 120-minute tape I used
(the maximum length), this came out to be 2.13 Gigabytes, or 2037
Megabytes. It took just under 2.5 hours to write the entire tape, for
an apparent rate of 243 kbytes/sec (memory to tape transfers only!).
--
Bill UUCP: {husc6,ihnp4,cmcl2,mit-eddie}!harvard!cfa!wyatt
Wyatt ARPA: wyatt@cfa.harvard.edu
(or) wyatt%cfa@harvard.harvard.edu
BITNET: wyatt@cfa2
SPAN: cfairt::wyatt