The network transfer rate is not particularly useful (see APAR IC30767),
so don't use that to judge your TSM performance. If you want a reasonable
idea of what how fast your TSM client can push data, your best bet is to
do a selective backup of a very large file (say, several hundred or more
MB), and look at the aggregate data transfer rate.

Regards,

Andy

Andy Raibeck
IBM Tivoli Systems
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: [EMAIL PROTECTED]

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




"Prather, Wanda" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
10/01/2001 09:35
Please respond to "ADSM: Dist Stor Manager"


        To:     [EMAIL PROTECTED]
        cc:
        Subject:        Re: performance question



Try running FTP.  Send a sizeable file (at least 100 MB) from your client
machine to the TSM server, several times, and see if you can get a
consistent MB/sec throughput rate.

If it is about the same as your TSM backup throughput, then the problem is
network related.
If it is a lot faster, then look for something in TSM, or in the client
file
system.

-----Original Message-----
From: Rob Schroeder [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 01, 2001 12:28 PM
To: [EMAIL PROTECTED]
Subject: Re: performance question


I have turned compression off, but to no avail.  The network card is not
set to auto-negotiate, and all the settings are verified and correct. Both
machines are well oversized with 512 MB of memory and dual processors that
are not being used anything but marginally.  Any other ideas?

Rob Schroeder
Famous Footwear




"PINNI, BALANAND (SBCSI)" <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 09/28/2001
06:14:52 PM

Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>

Sent by:  "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>


To:   [EMAIL PROTECTED]
cc:

Subject:  Re: performance question


Rob look at this o/p.I have only 100mbs/sec NIC Card.We also have fast
switches.
It should atleast give u 8mbs/sec network xfer rate.I do with
compression=yes on client side.
Try to do backup at some other time and see the throughput.
This is Unix client but of MIDRANGE.


09/28/01   09:59:17 --- SCHEDULEREC STATUS BEGIN
09/28/01   09:59:17 Total number of objects inspected:   62,218
09/28/01   09:59:17 Total number of objects backed up:      361
09/28/01   09:59:17 Total number of objects updated:          0
09/28/01   09:59:17 Total number of objects rebound:          0
09/28/01   09:59:17 Total number of objects deleted:          0
09/28/01   09:59:17 Total number of objects expired:         81
09/28/01   09:59:17 Total number of objects failed:           0
09/28/01   09:59:17 Total number of bytes transferred:   293.13 MB
09/28/01   09:59:17 Data transfer time:                    3.15 sec
09/28/01   09:59:17 Network data transfer rate:        95,162.04 KB/sec
09/28/01   09:59:17 Aggregate data transfer rate:        763.10 KB/sec
09/28/01   09:59:17 Objects compressed by:                   90%
09/28/01   09:59:17 Elapsed processing time:           00:06:33

-----Original Message-----
From: Rob Schroeder [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 28, 2001 2:33 PM
To: [EMAIL PROTECTED]
Subject: performance question


I am running TSM client 3.7.2 on a Win2000 server with Service pack 2. The
TSM server is Win2000 SP2 and using TSM 4.1.3.  I realize I need to
upgrade
the client, but I that will not happen until next week.  My dilemma is
this: the server backs up to the TSM server directly to a DISK pool that
is
quite large, the network is Gigabit, and this client is the only client
that is talking to the server.  There are no other applications running on
either server.  I would expect this baby to scream, but instead it is
dogging.  I am getting just 2 MB/sec throughput and would expect to be
pushing the network.  Here is the options file I am using:

LANG AMENG
tcpserveraddress fftsm01
changingretries 0
resourceutilization 10
schedlogretention 10
errorlogretention 10
compression yes
txnbytelimit 25600
largecommbuffers yes
tcpnodelay yes
compressalways no
tcpbuffsize 256
tcpwindowsize 50

Any ideas?

Rob Schroeder
Famous Footwear

Reply via email to