Author: Juergen Heinrich <jheinrich AT VERDI-AG DOT COM>
Date: Mon, 1 Oct 2001 11:36:07 +0100
Rob to get further details obout your client performance please set the following parameters in the client option file: TRACEFILE "C:\TSM\BACLIENT\TRACE\TRACE.OUT" TRACEFLAGS INSTR_CLIENT_DETAIL and
Author: Rob Schroeder <robs AT FAMOUSFOOTWEAR DOT COM>
Date: Mon, 1 Oct 2001 11:27:40 -0500
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 an
Author: "Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU>
Date: Mon, 1 Oct 2001 12:35:11 -0400
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
Author: Andrew Raibeck <storman AT US.IBM DOT COM>
Date: Mon, 1 Oct 2001 10:14:07 -0700
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,
Author: Marc Levitan <marc.levitan AT PFPC DOT COM>
Date: Mon, 1 Oct 2001 13:23:28 -0400
check to see what the port on the switch is set to. It might be set to auto-negotiate. just a thought... Marc Levitan Storage Manager PFPC Global Fund Services Rob Schroeder <robs@FAMOUSFOO To: ADSM-
The FTP transfer rate is very useful ... even if the ADSM network data transfer rate has bugs ... I believe I understand what Andy is referring to, but Wanda is referring to FTP. If FTP is for instan
Author: Rob Schroeder <robs AT FAMOUSFOOTWEAR DOT COM>
Date: Mon, 1 Oct 2001 14:04:16 -0500
I have tried the ftp and can transfer 500 meg in 45 seconds which is 9.7 MB/sec. So it does appear to be TSM that is responding slowly. Rob Schroeder Famous Footwear Jeff Bach <jdbach AT WAL-MART DOT
(Rob Schroeder wrote on apparently slow backups)... Assuming there are no strange messages in the schedule log (errors, warnings, retries), I'd try the following (individually): (1) for a windows cli
Author: Rob Schroeder <robs AT FAMOUSFOOTWEAR DOT COM>
Date: Fri, 28 Sep 2001 14:33:27 -0500
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
Author: Thorhallur Sverrisson <thorhs AT DEMON.NYHERJI DOT IS>
Date: Fri, 28 Sep 2001 20:01:07 +0000
In the first place, drop the compression. Compression is only intended for slow links where the amount of data sent over the wire is impotant. It is a huge CPU burden for the client to compress the d
Author: Bill Mansfield <WMansfield AT SOLUTIONTECHNOLOGY DOT COM>
Date: Fri, 28 Sep 2001 15:54:47 -0500
Turn compression off and see what happens. Client compression is not advisable with fast networks. What does your client CPU utilization look like? _____________________________ William Mansfield Sen
Test FTP throughput from client to server. Compare to backup speed. What are the number of files backing up? Is the 2 Meg/sec network transfer of aggregate? You can get up to 131 Gigs/hour using clie
Author: "PINNI, BALANAND (SBCSI)" <bp3965 AT SBC DOT COM>
Date: Fri, 28 Sep 2001 18:14:52 -0500
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
Author: Daniel Sparrman <daniel.sparrman AT EXIST-SWEDEN DOT COM>
Date: Sun, 30 Sep 2001 09:47:16 +0200
Hi Rob Have you tried setting the compression to no? There is no need to use compression on a gigabit interface, it will only slow the client down, and the wait time for the session will get higher.