Troy, I wouldn't mind assisting here but would like you to try the
suggestion here of the other posts that have been made. Could you try
backing up a single large file to your TSM server and provide to the
listserv the output from a client instrumentation trace (using the testflag
instrument:detail statement) and also (if possible) a server
instrumentation trace? The server instrumentation trace is started with an
'instr begin' command before the backup begins and then ended with a 'instr
end file=some.filename.txt" command when the backup finishes.


At 01:54 PM 2/2/2006 -0600, you wrote:

Here's some comparison data from a couple days worth of backups on our
two biggest groupwise servers...

- Server1 is 90GB (about 24GB daily change rate), with 1,000,000 files.
Hardware is Dual 2.4ghz Xeon's with 2.5GB RAM.
              - Last nights backup took 1h25min, and backed up 28GB.
              - Night before took 51min to backup 22GB

- Server2 is 77GB (about 24GB daily change rate) with 968,000 files.
Hardware is 3ghz Dual Xeon's with 2.5GB RAM
              - Last nights backup took 1h33min, and backed up 24GB
              - Night before took 52min, and backed up 25GB

So much faster speed than yours is definitely possible.   As people
have said, there's a lot of factors to weigh, but here's some more to
look at....
1.  Run some statistical trend graphs on the netware boxes, over the
last week.  This can be done in Remote Manager, and would tell you if
there's disk, network, cpu, or memory bottlenecks in the server
hardware.
2.  check the cfg files for the tsa's. (in sys:\ect\sms\tsa.cfg).
"Enable Caching" should be set to "no", as tsm does its own.  Also check
the "cache memory threshold.  Leave it as high as possible (25 is the
max), and reduce in increments of 5 percent if it gives you trouble.
3.   Update all the firmare & drivers for disk controllers and nic's.
4.  Have someone check the statistics on the switch ports of these
servers.  If you're seeing lots of crc errors,retransmits, or other bad
signs, then there's probably a speed/duplex problem between the nic &
switch.  There is no one rule that always works, so try all
possibilities (if you're hardcoding, try setting auto, and vise-versa).


>>> bwhitten AT UABMC DOT EDU 2/2/2006 12:38:41 PM >>>
Hi all,

Netware group at our location is not happy with backup
and restore performance using TSM. We are seeing roughly
4 to 5 GB per hour at best. We have tested going to SSA disk
pools, SATA disk pools and directly to 3590/3592 tape FC. We
don't see very much difference in these methods. Typical Netware
client is 150,00+ files with 25 to 40 GB per client. We also have
Groupwise and the performance for those is roughly 20 percent
worse.

Clients are mostly 5.1 and 5.2.

TSM servers are P615/4GB ram and P520/4GB ram running AIX 5.2
and TSM server 5.2.3

Most clients are GB Eth and we see similar performance on Windows
servers with similar volume sizes/number of files. It seems to me that
this is mostly a function of a large number of small files. We also
have
AIX, Solaris and Oracle clients and performance is generally better
on those clients (especially Oracle Rman/TDP).

I have looked through the postings and have not been able to glean
much of a consensus about what throughput should be for this type
of configuration. We have tried many of the parameter changes that
have been suggested ( buffer/tcp window sizes, quiet option, etc.)
without much success. If anyone has overcome these types of problems
or can give me some definitive answers ( even if the answer is 'that's
the
best you'll get' ), please e-mail me offline.

Thanks for reading and thanks to all who post on this site.


Brec Whitten

UAB Hospital


Confidentiality Notice follows:

The information in this message (and the documents attached to it, if any)
is confidential and may be legally privileged. It is intended solely for
the addressee. Access to this message by anyone else is unauthorized. If
you are not the intended recipient, any disclosure, copying, distribution
or any action taken, or omitted to be taken in reliance on it is
prohibited and may be unlawful. If you have received this message in
error, please delete all electronic copies of this message (and the
documents attached to it, if any), destroy any hard copies you may have
created and notify me immediately by replying to this email. Thank you.

Dave Canan
TSM Performance
IBM Advanced Technical Support
ddcanan AT us.ibm DOT com