miker@wjvax.UUCP (04/27/87)
here at WJ we wish to upgrade our magtape from .5 inch 1600 bpi
to a local maximum. Considerations include density,reliability,
and price ( of course! ).
not being familiar with mag media ANY help will be appreciated.
NOTE : salesmen welcome.
fyi : wjvax is a VAX 11/750 with total disk space == ~600M. Backups
will range from daily to permanent monthly.
thanks alot,
michael ryan
--
--------
michael j ryan
...!{ ucbvax!decwrl!qubix, mordor!turtlevax, ihnp4!pesnta}!wjvax!miker
disclaimer:
the above is not WJ's opinion,nope,not theirs,mine,all mine,yep,not theirs
--------
berger@datacube.UUCP (05/04/87)
On a similar subject of backup, anyone familiar with using Optical
Disks as a backup medium? How about users experience with commercial
backup utilities such as UBACKUP and BRU?
Bob Berger
Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960
VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125
UUCP: ihnp4!datacube!berger
{seismo,cbosgd,cuae2,mit-eddie}!mirror!datacube!bergerdem@uwslh.UUCP (David E. Miran) (05/05/87)
michael ryan writes > here at WJ we wish to upgrade our magtape from .5 inch 1600 bpi > to a local maximum. Considerations include density,reliability, > and price ( of course! ). At the Wisconsin State Hygiene Laboratory we are using an SI 9700 tape system on our VAX-11/750 with about 1.2 Gigabytes of disk space. This is actually a Storage Technology model 1953 Tridensity tape drive (800/1600/6250) that runs at 125 ips. The controller is a single board that is both massbus adaptor (or pretends it is) and tape controller. In our experience this unit is reliable and very fast. It is very expensive (we paid about $30,000 in 1984) for it and it is not state of the art (it has been out for at least 5 years). On the other hand, it runs at full speed (125ips) even at 6250 bpi while many of the modern inexpensive drives are 125ips at 1600 bpi and only 50 to 75 ips at 6250 bpi. We are very happy with it and I haven't yet seen anything that would give better performance if you want to be able to dump a lot of stuff to tape fast. This tape drive has a reputation as a very rugged unit. When we recently acquired a second computer we dual-port'ed the tape drive so that we share this one fancy drive between two computers. -- David E. Miran ...!{seismo,harvard,topaz,ihnp4}!uwvax!uwslh!dem Wisconsin State Hygiene Lab or dem%uwslh.uucp@spool.wisc.edu University of Wisconsin (608) 262-0019 465 Henry Mall Madison, WI 53706
chris@mimsy.UUCP (05/05/87)
In article <242@uwslh.UUCP> dem@uwslh.UUCP (David E. Miran) writes: >... we are using an SI 9700 tape system on our VAX-11/750 ... >This is actually a Storage Technology model 1953 Tridensity tape >drive (800/1600/6250) that runs at 125 ips. The controller is a single >board that is both massbus adaptor (or pretends it is) and tape >controller. In our experience this unit is reliable and very fast. But you may not be able to use all that speed. DEC disk drives tend to have low peak practical (by which I mean `file system style' through the raw device, i.e., /etc/dump) transfer rates: I have never observed more than 130KB/s from RA81s; I think our RP06s top out below 200KB/s. Our Eagles, on an Emulex SC78x, occasionally send more than 600KB/s, but more usually run in the 200 to 500 KB/s range. (Try running systat or iostat while dumping a drive to /dev/null.) >It is very expensive (we paid about $30,000 in 1984) for it and it >is not state of the art (it has been out for at least 5 years). >On the other hand, it runs at full speed (125ips) even at 6250 bpi >while many of the modern inexpensive drives are 125ips at 1600 bpi >and only 50 to 75 ips at 6250 bpi. At 125 in/s, assuming 32KB blocks (4.3BSD dump), 6250 B/in, .7 in gap: 32768 B/blk ----------- ~= 5.25 in (data) + .7 in (gap) = 5.95 in/blk 6250 B/in 5.95 in/blk ----------- = .0476 s/blk 125 in/s 32768 B/blk ----------- ~= 688 KB/s .0476 s/blk This means dump must provide at least 688 KB/s to your tape drive, or your tape is outpacing the rest of your system. *If* you can maintain a steady 600KB/s transfer rate from your disks, you can probably do this. If you have RA81s, forget it. (Of course, some clever person may speed dumps somehow, which could just throw all these calculations out the window. [Interleaved file systems, anyone?] But *at this time* those expensive 125 or 200 ips 6250 bpi drives are not worth it. We have one, and it *is* nice, but....) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
page@ulowell.cs.ulowell.edu (Bob Page) (05/06/87)
berger@datacube.UUCP (Bob Berger) wrote: >Has anyone had experience with using WORM Optical Disks as a backup medium? >As we approach 2 Gig on our network, even 6250bpi tape becomes a drag.... I recently got a brochure from a company that sells a WORM drive for about US$22K (list, if I remember right). Nice price, and they hold 2GB per disk. However, they are twice as slow as a DEC TU-81 (which is pretty slow to begin with), and the platters cost US$500 list, as compared to a dozen 2400' reels, which'll run you about US$240 list (assuming US$20/reel, Universities don't know always know the real cost of things :-) ) Also, you gotta buy the drive and driver, then pay a yearly maint fee for both. This is in addition to whatever tape drive you are currently using. You're not going to get rid of that, I assume. Advantages worth considering are: 1. Small backups (less than 2GB) can be done w/o operator intervention. If you have cheap operators, this probably isn't a concern. 2. Less space required for storage. If you're paying through the nose for floor space, converting to WORMs -might- save you money. You'd have to have a heckuva lotta tape cabinets, though, to see any benefit. Gotta buy cabinets to hold the WORM disks, too. 3. WORM's are random access - you can leave one on-line during the day for users/projects to read from. Nice for projects that have multiple versions lying around. The system that I saw only ran under VAX/VMS. I haven't seen anything for non-VAX, or even UNIX, at a reasonable price, yet. Followups to comp.periphs. ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.{uucpptheor\r\r
rwa@auvax.UUCP (05/06/87)
In article <242@uwslh.UUCP>, dem@uwslh.UUCP (David E. Miran) writes: > At the Wisconsin State Hygiene Laboratory we are using an SI 9700 > tape system on our VAX-11/750 with about 1.2 Gigabytes of disk space. > This is actually a Storage Technology model 1953 Tridensity tape > drive (800/1600/6250) that runs at 125 ips. [...] > We are very happy with it and I haven't yet seen anything that would > give better performance if you want to be able to dump a lot of stuff > to tape fast. I am currently using an SI 9700 as the _only_ tape drive on a network of Suns and Vaxes with about 2,900 Megabytes of disks in various flavours (and we fully expect to add another 2,00 or 3,000 Megs in the next year :-) which we back up to level 0 once a month, incrementals daily via the usual towers-of-hanoi scheme. The drive is about 4 years old now, and has had 2 major failures - the r/w head wore out, and a vacuum leak that made it refuse to load tapes. Total down time == about 3 days. We do our backups (the much maligned dump/restore pair) early in the mornings and usually have them done well before user load becomes serious. The drive is faster than the 11/785 it's tied onto right now; a Sun 3/280 _might_ be able to race it, but there's no way to find out since I don't have a 3/280 (yet!). I like the drive, and recommend it highly. The only problem with it is that sometimes it won't autoload small (600') reels, and then you have to intervene manually. I don't know if this is the best price/performance example around, but the performance itself is fine.
rwa@auvax.UUCP (05/06/87)
In article <6567@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > But you may not be able to use all that speed. DEC disk drives > tend to have low peak practical (by which I mean `file system style' > through the raw device, i.e., /etc/dump) transfer rates: I have > never observed more than 130KB/s from RA81s; I think our RP06s top > out below 200KB/s. Our Eagles, on an Emulex SC78x, occasionally > send more than 600KB/s, but more usually run in the 200 to 500 KB/s > range. (Try running systat or iostat while dumping a drive to > /dev/null.) Ok, I just did that. "dump 0f /dev/null /dev/rra1h & iostat 1". System is an 11/785, 24 megs of core (whoops, RAM) running Ultrix 1.2; interface to the ra81 is via uda50 sitting on a private unibuss/dw780 (actually shared with a deuna, but net traffic is light), said uda50 has the 'buss-wait' jumper set to zero. Measurements were made under light load (load avg. about 2, 33 users, at about 2 in the afternoon). Iostat reported average transfer rates in the 290 Kb/s to 350 Kb/s range. /dev/ra1h is an 8k/1k filesystem of about 360 megabytes. The main hack here was to set the burst-transfer counts higher. Look at the comments in /usr/sys/data/uda_data.c about hog-mode and try setting ud_burst to something larger than the default 0 (I am using 3, but maybe even higher would work ? I _must_ sit down and experiment! OK, everybody off the machine _NOW_!! ). At-any-rate, ra81's aren't complete slugs. But Chris is right, the machine _still_ can't keep up to the tape drive when dumping. The pauses for thought are obvious. As an aside, until I put the uda50 and deuna onto their own unibuss, auvax was a very unstable machine. All kinds of terminal wedging, net crashes, and general unpleasantness. Blecherous. And the disks were slow then too. Private to Chris: how did you get your eagles to go so fast? I have some tied to a 780 via an SI 9900 and I don't think I ever saw +500 (or even +300) Kb/s out of them. Suggestions gratefully accepted :-). -- ...!ihnp4!alberta!auvax!rwa Ross Alexander, Athabasca University
mangler@cit-vax.UUCP (05/17/87)
In article <6567@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek)
calculates the average throughput of 6250-bpi tape, and gets
the right answer despite two misconceptions.
The ANSI standard gap length for 6250-bpi tape is 0.3 inches,
Most manufacturers fudge on this, and come out somewhere around
0.4 inches; certainly well under the 0.7 inches that Chris assumed.
During the interrecord gap, the tape is accelerating/decelerating,
and on average will be moving at half normal speed. So a gap of
0.4 inches will take as much time as 0.8 inches of normal motion.
speed * blocksize
Throughput = ---------------------------
2*gap + blocksize/density
For 125 ips, 0.4 inch gap, 6250 bpi, 32KB blocks = 678 KB/s.
For 125 ips, 0.7 inch gap, 1600 bpi, 10KB blocks = 164 KB/s.
The 1600-bpi figure is consistent with the peak speed I measure
on my TU77, doing write() in a tight loop. Dump throughput is
only 80-90% of this (we have tens of thousands of tiny files).
Despite the details, Chris's conclusion still stands. (I'd say
the point of diminishing returns is about 45 ips @ 6250 bpi).
Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speckmangler@cit-vax.UUCP (05/17/87)
In article <161@auvax.UUCP>, rwa@auvax.UUCP (Ross Alexander) writes: > ...how did you get your eagles to go so fast? There are several factors affecting raw I/O throughput with Eagles. First off, Emulex controllers are a millisecond faster than SI 9900's. Assuming you have sector & index on the "B" cable, the Emulex will always knows which sector is coming up; the SI 9900 has to find out by selecting one drive and looking at the headers that are flying by. (Like the Xylogics 450). Notice the non-functional RMLA register. Unfortunately, on controllers that do implement RMLA, the 4.2 and 4.3 BSD drivers throw away disk revolutions by incorrectly deciding whether the requested sector is "coming up soon". The 4.3 version can be made correct by reversing the sense of the test, and swapping all the sdist and maxdist numbers. This makes about a 25% difference. Surprisingly, tunefs makes little difference in dump throughput, because of contention from 4.3 BSD dump's multiple processes. In a disk-limited situation, the context switch rate will soar to 300 per second, as processes fight over one raw I/O buffer header. An easy change to hpread(), allowing any of its raw I/O buffers to be used with any of its disks, improves dump throughput by 25%. Raw I/O has less per-kilobyte overhead in 4.3 than in 4.2 BSD. Increasing dump's tape blocksize has the side-effect of improving disk throughput, by making the read buffer larger. This means fewer disk reads broken across tape blocks, and fewer context switches; a throughput improvement of about 15%. Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speck