Not always................but on a number of occassions I seen long running backups on Windows servers because they have the nic card set at an explicit setting, and the network has auto-negotiate on the ports, or some such mismatch between the client NIC and the port config.
>>> [EMAIL PROTECTED] 03/22/07 2:33 PM >>> Hello, We have about 5 or 6 Windows Servers whose backups performance is very very poor these backups start a midnight and run throughout the whole day and sometimes run for a couple days I have been reading different options including the DISKBuffsize option, I know poor networking performance can be caused by a number of factors and not sure which parameter to look at first. Here is an example of one of the clients dsm.opt file, They all basically look the same and the parameters matches TSM windows clients recommendations. Lang Ameng Domain ALL-LOCAL TCPSERVERADDRESS xxxx.xxx.xxxxx.xx.xx Passwordaccess generate TCPCLIENTADDRESS xx.xx.xxx.xx NODENAME xxxx SUBDIR YES REPLACE PROMPT TCPB 32 TCPW 63 SCHEDMODE PROMPTED TXNBYTELIMIT 25600 ERRORLOGNAME SCHEDLOGNAME ERRORLOGRETENTION 14 SCHEDLOGRETENTION 7 TCPNODELAY YES RESOURCEUTILIZATION 3 LARGECOMMBUFFERS YES CHANGINGRETRIES 2 COMPRESSION BACKUPREG YES MANAGEDSERVICES WEBCLIENT SCHEDULE Windows 2000 and 2003 servers TSM server 5.3.4 TSM client 5.3.4 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain information that is confidential, privileged, and/or otherwise exempt from disclosure under applicable law. If this electronic message is from an attorney or someone in the Legal Department, it may also contain confidential attorney-client communications which may be privileged and protected from disclosure. If you are not the intended recipient, be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Please notify the New York State Thruway Authority immediately by either responding to this e-mail or calling (518) 436-2700, and destroy all copies of this message and any attachments.