[comp.os.vms] Megatape 8mm backup device

chris@mimsy.UUCP (Chris Torek) (11/20/88)

(Capsule review: It seems to be generally believed that 8mm backup units
like the Exabyte cannot be made to work on a DWBUA (BI) Unibus, yet the
real transfer rate on these tape drives is less than 250 kilobytes per
second, so it should be possible to find some controller/tape pair that
works.  We now know of one such pair.)

Over the past few days, the Computer Science Department at the
University of Maryland has evaluated an 8mm tape system manufactured by
Megatape Inc.  The box has the same Sony transport that is used in the
Exabyte, and uses the Exabyte data format.  Both manufacturers claim
that this format is designed to be insensitive to real tape errors.  We
saw no errors with the demo unit, at any rate.

The Megatape uses a Pertec interface and thus will connect in place of
an existing Pertec transport, such as the CDC transport DEC sells as
the TU80.  Our DEC TU80, however, is run by a Dilog controller (I do
not know which model; it says `Ditronics' on the card, but when
compared with a Dilog controller, appears identical.)  The Dilog
controller has little buffering, and when connected to the Megatape,
suffers Data Late timeout errors at read speeds above about 70 kB/s if
there is much bus traffic, presumably due to the long response latency
on the 8250 Unibus.  One can write at higher rates, up to about 250
kB/s.  The Megatape box has a 512 kB cache, and can speak different
speeds with the controller, as it normally reads and writes the tape
from the cache, so burst rates are not a problem.  (The speeds are: 40,
60, 73, 120, 200, 250, 273, 300, 333, 375, 400, and 500 kB/s.)

Megatape recommends (and resells, but Emulex sells it for less, at
least to Universities) the Emulex TC13 controller, which has more
buffering.  With the TC13, we had no trouble reading 32kB blocks at 250
kB/s.  Actual throughput as measured on the 8250 system, which is
reading from CDC 9771 disk drives attached to an Emulex SC41/MS
controller, all on the (single) Unibus, is about 110 kB/s for
4.3BSD-tahoe `dump'.

Using the Megatape/TC13 combination on a 785 with UDA50s and (again)
one Unibus, I got about 170 kB/s for one file system.  On an 8600 with
Eagles on an Emulex SC780 (massbuss emulator), throughput was over 210
kB/s, or about 85% of the theoretical maximum (continuous) transfer
rate for this transport.  (All these numbers err slightly on the low
side, and the 8600's Eagle driver has not yet been retuned for the
machine; we really should be able to do better than this.)

The units can be daisy-chained, and one of the two models has a dual
interface with an A/B switch on the front panel.

Each 8mm cartridge will store approximately 2.3 GB of data; tapes are
available in most video stores for about $10 each (look for `Sony MP120').

Not all is roses, however:

The TC13 emulates the DEC TS11 and equivalent.  You will have some
trouble if you cannot prevent your TS11 driver from attempting to
backspace by records or files, as these units cannot do this: they can
only read forwards.  It is possible to disengage the head and wind the
tape in either direction, but this is not currently supported, other
than for a full rewind.  The 4.3BSD-tahoe Unix TS11 driver normally
writes two tape marks, then backs up over the second, so as to provide
a proper end-of-file and end-of-tape.  Changing this is trivial, but if
you run Ultrix you will need source, or else you will have to rewind
after each tape file, then use `mt fsf' to skip forward.  This is
rather slow.  Rewind time is 135 seconds, but reading a full 2.3 GB is
very slow---at 250 kB/s, this would take over two and a half hours
---and forward skips are not much faster than plain reading (about
4x, or 40 minutes---this from memory; the information is not in the
Megatape manual).

The manual we have is marked `preliminary'; presumably the unit we
have is in beta test.  At any rate, it seems to get confused after
being told to backspace, then to write.  The only way to recover is
to power-cycle the Megatape box.  There may be a few bugs left yet.

Rumour has it that the Sony 8mm transport heads degrade rapidly (just
how rapidly is not rumoured, but such is the nature of rumours).

Summary: it works, and being able to back up everything on a single
tape cartridge is very attractive.  The Megatape unit is faster than
what we now have on the two 8250s (the second 8250, on which we did not
test the unit, has RA81s on a KDB50), and slower but less expensive
than what we have on the other VAXen (TU78s).  The unit also works
well on Suns.  We will probably buy several.

I should also note that Megatape was very helpful, including shipping
us a TC13 after we had tried the box with the Dilog controller.  Thanks
are due to Rich Long, Ed Mortenson, and Tom Millican of Megatape.
(Those of you who have heard me rant against Emulex may be pleased to
discover that I do not hate all perhiperhal manufacturers. (-:
Incidentally, if you call Megatape, you might mention us, and this
review.  Never hurts to build up name recognition :-) ---heck, maybe we
can even convince Emulex that when we say their controller [here I mean
the SC41/MS] has a bug, we might be right....)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

chris@mimsy.UUCP (Chris Torek) (11/21/88)

Some corrections to article <14650@mimsy.UUCP> (by me):
>The Megatape box has a 512 kB cache ....

Steve said `Oops, make that 1.2MB or 1.5MB'.  (Well, that too was not
in the manual, or I missed it, but apparently it was a recent change
that improved performance [I would guess so---why manufacturers think
less than 1 MB is a `big' cache is beyond me...].  Preliminary manuals
can be expected to need changes, I suppose.)

>You will have some trouble if you cannot prevent your TS11 driver from
>attempting to backspace by records or files, as these units cannot do
>this ....

Bill Wyatt (at Harvard's CFA) tells me that backspace by file is
possible, but to backspace over a tape mark, they will have to use the
`long' tape mark format.  I got errors back from the TC13 after each
attempt to write after a backspace, so either there is a bug in the
firmware, or they are using short marks.

>... forward skips are not much faster than plain reading ...

Bill says `more like 10x'; that is considerably better: about 15
minutes to position over a full tape.

Anyway, we still like it.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

chris@mimsy.UUCP (Chris Torek) (11/21/88)

Corrections to the corrections in article <14653@mimsy.UUCP> . . . :
>...  I got errors back from the TC13 after each
>attempt to write after a backspace, so either there is a bug in the
>firmware, or they are using short marks.

... or the TS11 driver in 4.XBSD (and hence presumably Ultrix) uses
TS_SREV (backspace record), not TS_SREVF (backspace file).  Oops.
Back to my original position: it is trivial to fix if you have source.
If you have object code only, you can probably still patch it.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris