offsiting to Virtual Volumes slow?

[stephrf]

Hi, I have inherited 2 TSM instances which offsite to each other using virtual volumes using a
dedicated 1 Gigabit ethernet link. The device classes all have a capacity of 20,480.0.

Server A copies poola to poolremotea and Server B copies poolb to poolremoteb.

A. the copies are slow and sometimes very slow.
b. filesize copied is from aprrox 100 mb to 250gig
c. simultaneous cross copying - depending on when various housekeeping runs.
d. various pools cross copied - varying sizes daily
e. used for both DB snapshot and copy pools


I am planning to ask for more tape drives on ServerB(money permitting) to take at least half
the traffic off the above method - so only one side vaults to the other using virtual volumes.

Does anyone have any tips on how to speed this up? Network tell me the link is only
50-70% utilised.
thanks rob

 

[Trident]

Hi,
TSM version?
OS type and version?
Ping latency?

These could be helpful to know.

I good tip is to set TCPWindowSize to 0 (helped me running redhat and tsm 5.5)

 

[stephrf]

Hi Trident, I will look at

1. TSM version is 6.1.4.1
2. AIX 6.1
3. A: TCPWindowsize 64512 b: TCPWindowsize 64512

I will check the values for AIX - thanks.


Pings:

server a to server b:

ping 10.172.7.250
PING 10.172.7.250 (10.172.7.250): 56 data bytes
64 bytes from 10.172.7.250: icmp_seq=0 ttl=251 time=6 ms
64 bytes from 10.172.7.250: icmp_seq=1 ttl=251 time=7 ms
64 bytes from 10.172.7.250: icmp_seq=2 ttl=251 time=6 ms
64 bytes from 10.172.7.250: icmp_seq=3 ttl=251 time=6 ms
64 bytes from 10.172.7.250: icmp_seq=4 ttl=251 time=6 ms
64 bytes from 10.172.7.250: icmp_seq=5 ttl=251 time=6 ms
64 bytes from 10.172.7.250: icmp_seq=6 ttl=251 time=6 ms

traceroute to 10.172.7.250 (10.172.7.250) from 10.170.7.12 (10.170.7.12), 30 hops max
outgoing MTU = 1500
1 10.170.7.3 (10.170.7.3) 11 ms 0 ms 1 ms
2 10.170.28.162 (10.170.28.162) 2 ms 1 ms 1 ms
3 10.172.28.114 (10.172.28.114) 7 ms 7 ms 7 ms
4 10.172.28.193 (10.172.28.193) 8 ms 7 ms 8 ms
5 gsams-axl-tsmserver (10.172.7.250) 7 ms 7 ms 7 ms


server b to server a:

PING 10.170.7.250 (10.170.7.250): 56 data bytes
64 bytes from 10.170.7.250: icmp_seq=0 ttl=251 time=6 ms
64 bytes from 10.170.7.250: icmp_seq=1 ttl=251 time=7 ms
64 bytes from 10.170.7.250: icmp_seq=2 ttl=251 time=6 ms
64 bytes from 10.170.7.250: icmp_seq=3 ttl=251 time=6 ms
64 bytes from 10.170.7.250: icmp_seq=4 ttl=251 time=6 ms
64 bytes from 10.170.7.250: icmp_seq=5 ttl=251 time=6 ms
64 bytes from 10.170.7.250: icmp_seq=6 ttl=251 time=7 ms
64 bytes from 10.170.7.250: icmp_seq=7 ttl=251 time=7 ms
64 bytes from 10.170.7.250: icmp_seq=8 ttl=251 time=6 ms

traceroute to 10.170.7.250 (10.170.7.250) from 10.172.7.250 (10.172.7.250), 30 hops max
outgoing MTU = 1500
1 10.172.7.3 (10.172.7.3) 38 ms 1 ms 0 ms
2 10.172.28.194 (10.172.28.194) 1 ms 1 ms 1 ms
3 10.172.28.113 (10.172.28.113) 7 ms 9 ms 7 ms
4 10.170.28.161 (10.170.28.161) 7 ms 7 ms 7 ms
5 londc-axl-tsmserver (10.170.7.250) 7 ms 7 ms 7 ms

thanks Rob

 

[Jeroen]

try a ftp outside TSM to be able to compare the throughput rates.

We were never able to get over ~60MB/sec using a gbit connection for virtual volumes.
Once we got the possibility to offsite over the SAN, we moved away from virtual volumes immediately.

 

[Trident]

Hi,

IBM info:

http://publib.boulder.ibm.com/infoc...ze.html&resultof="tcpwindowsize" "tcpwindows"
http://publib.boulder.ibm.com/infoc...ze.html&resultof="tcpwindowsize" "tcpwindows"

 

[stephrf]

Guys, Trident thanks for the links.

Jeroen, thanks for your suggestions.

regards Rob