Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site calma.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!sun!calma!radzy From: radzy@calma.UUCP (Tim Radzykewycz) Newsgroups: net.micro,net.periphs Subject: Re: streamer tapes Message-ID: <91@calma.UUCP> Date: Fri, 6-Dec-85 12:44:08 EST Article-I.D.: calma.91 Posted: Fri Dec 6 12:44:08 1985 Date-Received: Mon, 9-Dec-85 03:35:54 EST Reply-To: radzy@calma.UUCP (Tim Radzykewycz) Organization: GE/Calma Co., R&D Systems Engineering, Milpitas, CA Lines: 62 Xref: watmath net.micro:12994 net.periphs:932 In Article 3936 of net.micro jchapman@watcgl.UUCP (john chapman) writes: >(I realize this might better have been in net.periphs but it seemed > particularily oriented to micros to me.) >There are various ads for tape backup for micros; these seem to >fall into two (neglecting the few 9track ads) categories: floppy >emulators (shades of Dectape!) and streaming tape. The streamers >seem somewhat more attractive due to their higher capacities, but..... >Question: some of the ads for streaming tape claim not only image > read.write of a file system but also selective retrieval > of individual files (and selective writing?). I was > under the impression that streamers were an all or nothing > sort of affair. Can this really be done (and is it a > matter of software, interface or drive)? Can a streamer > (or perhaps only some streamers) perform the operations > you would normally expect of a 7/9/ track magtape? In my past experience with streaming tape drives, I've always found that streaming tape drives work in a semi-strange way: Whenever you start an operation, when the tape is stopped, the drive first needs a certain amount of "ramp-up" time to get the tape up to speed. Whenever you stop the operation, the drive takes roughly the same amount of time to stop the tape from spinning. Most systems that I've used with fast streamer tape drives can't feed data to the drive fast enough to keep the drive streaming continuously. What happens is that the drive ramps-up, does its read, and then ramps back down. Then, the drive rewinds the distance needed to get to the position where it will be able to start the next read at the location on the tape where the next data is. In any case, this is largely transparent to the application. It simply says to read the next block, and the controller/drive do the rest. This does give you the ability to take individual files off the tape or put individual files onto a tape. The only problem is that working in that mode generally doesn't give you very good performance. The first such drive I worked with was a 9-track that would stream at 100ips and work in start/stop mode at 10ips -- the start/stop mode at 10 ips was *faster* than the streaming mode at 100ips! I should also mention that the ramp-up/down time on that drive was 6 inches (6 inch ramp-up, 1/4 inch read, 6 inch ramp-down, 12 inch rewind -- yuck). If I could have made the system feed data to the tape fast enough to keep it streaming, then it would have been fast, but the controller wouldn't allow such things. For those of you with a little curiosity: Why do that? The reason is quite simple. If you don't have to worry about changing from 100 ips to a standstill in less than 1/4 inch, then you can easily use *much* cheaper drive motors. The electronics design does get a little tougher, though, because of the ramp-up/ rewind/ramp-down, but that is insignificant compared to the drive motors. This really should be in net.periphs, so I'm cross-posting this there. -- Tim (radzy) Radzykewycz, The Incredible Radical Cabbage calma!radzy@ucbvax.ARPA {ucbvax,sun,csd-gould}!calma!radzy