[comp.os.vms] More 6250 tape drive

MCGUIRE@GRIN2.BITNET (06/04/87)

I'm forwarding the following contribution to the discussion on 6250 tapes.

------------------------------ Begin Attachment ------------------------------
Received: From UKACRL(MAILER) by GRIN2 with RSCS id 1617
          for MCGUIRE@GRIN2; Wed,  3 Jun 87 14:47 CST
Received: By UK.AC.RL.IB (MAILER) ; Wed, 03 Jun 87 15:16:41 BST
Via:      UK.AC.ULST.UCVAX;  3 JUN 87 15:16:36 BST
Date:     3-JUN-1987 15:19:51
From:     NETWORK%UK.AC.ULSTER.UCVAX@AC.UK
To:       MCGUIRE@GRIN2
Subject:  info-vax discussion on 6250 bpi tape backup

I've a few comments to make re your submission. I can't contact
info-vax or dneiman%carleton.edu@relay.cs.net directly.

1. Backup from a fragmented disk is much more likely to be CPU
and/or disk I/O bound than either a restore or a full backup from
a non-fragmented disk.

2. We don't have HSC50 at our site. However for normally connected
TU77 on 780 vs. normally connected TU81+ on 8700 we have the
following observations:

a. Tape usage is reduced by a factor of four. A full RA81 (just)
fits onto two reels at 6250 whereas the same disk would take 8 or
9 reels at 1600.

This has obvious implications in terms of rewind time and time
wasted by operators loading tapes. It also makes buying tapes,
humping them to/from the safe and storing them much less painful.
It also makes locating a given single file for restore much, much
faster - this benefit is noticeable even on daily incrementals.

b. Using dual drive techniques to eliminate rewind time wastage,
the TU81+ is SEVEN TIMES faster than the TU77. This is partly
due to the increased density, partly to the higher linear speed,
partly to an 8700 having sufficient CPU power to do the job (!)
and partly due to the cache in the TU81+ managing to keep the
thing streaming, rather than being in start/stop mode.
(Measured, of course, on a full standalone dump/restore. The speed
benefit on incremental dumps is much more marginal since selecting
the relatively few files which actually need dumping tends to take
longer than actually dumping them.)

c. Using /BLOCK=65000 we have found dodgy at 1600 bpi, sometimes
there isn't enough tail on the tape and the end comes off the
reel 'cos the drive can't finish its block write and stop in time.
This isn't a problem at 6250 bpi.

d. DEC have designed the TU81+ so it only works with "standard"
tapes. The long 3200' or 3600' tapes confuse the spindle servo
program. Maybe the TU78 doesn't have this problem, I'm not sure.

Personally, if I was buying a new system, I would DEFINITELY
specify 6250 bpi for the tape drive(s) even on a small system.
Of course a 1600 bpi mode (available on TU81+) is mandatory for
information interchange.

                                                Brian Beesley
                                                SCO Data Comms
                                                Univ. of Ulster

Disclaimer: I'm not endorsing any particular product. I'm only
stating what we have observed. It's impossible for me to predict
how (if at all) any given kit would operate on other people's
systems.
------------------------------ End Attachment ------------------------------