On maandag, juli 15, 2002, at 10:48 , Mark Stapleton wrote:

From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Gill, Geoffrey L.

Can anyone relate this extremely slow backup to any issues they know
about
TSM or Solaris. The client has 10GB of data, the first 2GB of
which tool 2.5 hours to transfer, then I killed it from my end. At the

rate

it was going it was going to take 95 hours to complete.

I'm told there is no mismatch in NIC/Switch settings.

(I've heard *that* before.) Be absolutely sure that all network
connections
(NICs, switch ports, etc.) are *all* hard-set to the same (proper)
speed and
duples settings. (You're almost always better off avoiding
"auto-negotiate"
as the setting.) Run an ftp session to check against your TSM transfer
speed.

Been there, found that suns work perfectly with cisco switches in auto
negotiation. Most likely, host negotiated half-duplex and switch set
hard to full duplex.

Large amounts of packet loss also greatly impact te speed of your
backups. Maybe it's not the node's link, but one in between the node and
the server, what does ftp-ing a file between sever and node do? Same?
What if you ftp between another node on the same lan and you server?
What between the two nodes? All of this may help you isolate your
(network) problem.

---
Met vriendelijke groeten,
Met vriendelijke groeten,

Remco Post

SARA - Stichting Academisch Rekencentrum Amsterdam    http://www.sara.nl
High Performance Computing  Tel. +31 20 592 8008    Fax. +31 20 668 3167

"I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course - the computer
industry
didn't even foresee that the century was going to end." -- Douglas Adams