As much of a performance hit as you want !
With about every TSM task (straight backups via "resourceutilization" or
with tdp/r3 with the number of concurrent sessions, etc...) you can tune how
busy TSM will keep your system.
We have our production boxes at one site and our disaster recovery center
miles away, our TSM server(s) are located at the DR site, we have to
compress all client data to send it across the OC12 between the sites.  For
example, we can crank up TSM activities to suck up 90% of 20 processors (out
of 32) on a Sun E10K by using client compression...
So an OC12 is 622 Mb/sec or roughly 273 GB/hr, on a nightly basis we see it
running somewhere between 175-200 GB/hr so we still have about 1/3 capacity
BUT we see 3.8/1 compression of most data base data so we are actually
moving somewhere around 760 GB/hr of client filespace and I'd hate to be
pay'n for an OC24 (or more) between the sites (if we could even get it) !

One view is that if you beef up the processors to assist in backup, the end
results to the user community is increased performance during their
production use ;-) It's a (god I hat to say this) "WIN ! WIN ! situation...
Just remind management that today they are more than ever likely to have to
depend on their DR !


Dwight



-----Original Message-----
From: Conko, Steven [mailto:sconko AT ADT DOT COM]
Sent: Wednesday, November 20, 2002 2:35 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: tape-to-tape performance


thanks for that insight. i forgot to mention we are running fibre channel
and not scsi drives. yes, the data is must have... it is all production data
and is being copied for DRM.

how much of a performance hit will it take to turn compression on at the
client level?

-----Original Message-----
From: Cook, Dwight E [mailto:DWIGHT.E.COOK AT SAIC DOT COM]
Sent: Wednesday, November 20, 2002 3:22 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: tape-to-tape performance


Is 1.6 TB the amount of "must have/critical" information ?
and is that already compressed ?
Knowing each tape mount runs about 90 seconds, any way to reduce tape mounts
will speed up copies.
If you have collocation on, turning it off ~could~ help... and collocation
can/is set on both primary pools and copy pools.
Now if the data isn't compressed by the client the data is uncompressed at
the drive, moved through the processor as ~full size~ data, then
recompressed at the destination drive.  If your clients have the horsepower,
turn on client compression, that way not so much data is moved across the
processor's buss.
Don't daisy chain any of your 3590's if they are older scsi.
You might be able to reduce your data down if you force the application
owners to review their required CRITICAL/MUST HAVE data and send it to
isolated pools for copies to take offsite.

just some thoughts...

Dwight

-----Original Message-----
From: Conko, Steven [mailto:sconko AT ADT DOT COM]
Sent: Wednesday, November 20, 2002 1:26 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: tape-to-tape performance


we run a 3494 tape library with 3590 tape drives. after our backup are
finished, we run a backup stgpool to a copy pool on about 1.6TB of data. as
you can imagine, even with 8 drives this takes some time. are there any
server, device or other parameters we can tune to improve the tape-to-tape
performance?


steve