Jim,

Except that the tape is a 4GB tape, rated as 8GB WITH compression.

Point taken on the speed of the DUPTAP.  I'm reasonably satisfied with it
taking that into account.

..Neil





Jim Damato <jdamato@dollargeneral.com>
Sent by: midrange-l-admin@midrange.com
2002/01/15 11:30
Please respond to midrange-l


        To:     "'midrange-l@midrange.com'" <midrange-l@midrange.com>
        cc:
        Subject:        RE: DUPTAP command


>  Neil:
> Saturday morning went to a model 270 (with CPW 950) to do DUPTAP from
8mm
> to an SLR5-4gb (4/8GB tape) on a 6382 QIC drive, reading from a 7208-342
> 8mm drive.  DUPTAP took just over 6 hours !!  Also, weird thing is we
kept
> waiting for message to change QIC tape after about 8GB, but the message
> never came.  It actually wrote all 13.7GB to a single 4/8GB tape (in
> format QIC4DC).

> It makes absolutely no sense to me why DUPTAP takes so long to run -
even
> longer than to run the actual save or restore jobs on much slower
systems
> (although the restricting speed is no doubt the write speed to an
SLR5-4GB
> tape, not the CPW of the box).  Anyone else have any annoying
experiences,
> or knowledge, on this stupid command ?


QIC4DC is a compression format.  Depending on the data I've seen better
than
50% compression in the past, so 13.7GB to an 8GB tape doesn't surprise me.
Neither does 6 hours to dup a tape of that size with the formats you've
used.  According to the V4R4 System Handbook the 6382 performs at about
760
K/sec in QIC4DC format.  Doesn't that work out to about 2.7GB/hour?

Slower vs. faster systems and the command itself don't seem to really
figure
into the situation too much.  It seems to all boil down to the target tape
drive.  I'd like to see what performance you get backing up a few gig
straight onto the 6382 from disk via SAVOBJ.

-Jim

James P. Damato







As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.