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