Re: Network settings and poor backup performance.
Dear Rafa, could you me an invitation to get a gmail account? Thanks --.. -Original Message- From: Rafa <[EMAIL PROTECTED]> To: ADSM-L@VM.MARIST.EDU Sent: Wed, 30 Nov 2005 12:24:36 -0500 Subject: Re: [ADSM-L] Network settings and poor backup performance. On 11/30/05, Ray Louvier <[EMAIL PROTECTED]> wrote: Can anyone give the technical reason why auto detect on Server NICs cause such horrible performance for TSM server backups and restores. We This sounds like a network problem, not a TSM one. Quick way to prove it: try a backup/restore to another server on another location. I had a similar problem recently. My TSM servers are connected with gigabit ethernet interfaces to cisco switches. This cisco connected to another cisco switch where there was a 100Mbit connected server. Performance was dismal and the server interface showed CRC galore. The NIC on the server and the switch port were set to autodetect and both reported being 100mbit full duplex. The only way to solve this issue was to shutdown the interface and bring it back up again so they would renegotiate. Both still reported 100Mbit full but the CRC went away. This very same thing happened on two other servers. I don't know why the "hocus pocus" fixed it since nothing seems to have been changed but it worked. Advice: check for CRC. ___ Try the New Netscape Mail Today! Virtually Spam-Free | More Storage | Import Your Contact List http://mail.netscape.com
Re: Network settings and poor backup performance.
==> On Wed, 30 Nov 2005 10:20:59 -0600, Mark Stapleton <[EMAIL PROTECTED]> said: > > This is a bone of network contention (no pun intended), particularly with > Cisco networks. It is *not* a TSM problem. (As usual, TSM is the World's > Best IT Infrastructure Problem Finder.) What he said, but louder. I have a nearly autonomic response to new clients; very very often the initial backup goes very slowly, I suggest they check duplex settings, and things get going. - Allen S. Rout
Re: Network settings and poor backup performance.
On 11/30/05, Ray Louvier <[EMAIL PROTECTED]> wrote: > > Can anyone give the technical reason why auto detect on Server NICs > cause such horrible performance for TSM server backups and restores. We This sounds like a network problem, not a TSM one. Quick way to prove it: try a backup/restore to another server on another location. I had a similar problem recently. My TSM servers are connected with gigabit ethernet interfaces to cisco switches. This cisco connected to another cisco switch where there was a 100Mbit connected server. Performance was dismal and the server interface showed CRC galore. The NIC on the server and the switch port were set to autodetect and both reported being 100mbit full duplex. The only way to solve this issue was to shutdown the interface and bring it back up again so they would renegotiate. Both still reported 100Mbit full but the CRC went away. This very same thing happened on two other servers. I don't know why the "hocus pocus" fixed it since nothing seems to have been changed but it worked. Advice: check for CRC.
Re: Network settings and poor backup performance.
Because nic & switch vendors never seem to implement the autodetect spec in the same and/or correct way. Depending on the manufacturer of the switch/nic, sometimes you have to use auto on both, sometimes you have to hardcode both, sometimes you have to hard code one but set the other to auto. There's very little rhymm, reason, or predictability. You just have find out what usually works with your particular combination of equipment. This makes it very difficult if you don't have standardized hardware in your environment, and have to figure this out for every individual combination of equipment. The exception to this is if you've got a gigabit nic plugging into a gigabit switch. That link virtually always has to be set to "auto" on both ends if you want to get gigabit speed. >>> [EMAIL PROTECTED] 11/30/2005 10:00 AM >>> Can anyone give the technical reason why auto detect on Server NICs cause such horrible performance for TSM server backups and restores. We have our TSM server NIC set to 100MB Full also our switch Port set to 100 Full but we have users with sorted networks such as 1 GB switches plugged into 100 M wall jacks and travel across several routers., well you get my meaning. These people or demanding to know why they take 8 days to restore 6 GB. They have their server NIC set to Auto detect, They have a 1 GB switch that the server and several others are plugged into because they want hi speed between these servers. But this switch plugs into a normal 100 meg wall jack to get to our data center. I have instructed them to put the NIC to 100 Full and possibly move off swith but they want a technical reason why. They are developers. -- This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message. Confidentiality Notice follows: The information in this message (and the documents attached to it, if any) is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken, or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this message in error, please delete all electronic copies of this message (and the documents attached to it, if any), destroy any hard copies you may have created and notify me immediately by replying to this email. Thank you.
Re: Network settings and poor backup performance.
"ADSM: Dist Stor Manager" wrote on 11/30/2005 10:00:06 AM: > Can anyone give the technical reason why auto detect on Server NICs > cause such horrible performance for TSM server backups and restores. This is a bone of network contention (no pun intended), particularly with Cisco networks. It is *not* a TSM problem. (As usual, TSM is the World's Best IT Infrastructure Problem Finder.) There are any number of whitepapers, Cisco and otherwise, that insist that all NICs in all networks have speed and duplex settings hardset to the best speed suited to the network hardware. The problem with autonegotiate is that, unless *every* network device in the chain is set to autonegotiate, the entire chain runs at 10/half. -- Mark Stapleton ([EMAIL PROTECTED]) -- Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. ==
Network settings and poor backup performance.
Can anyone give the technical reason why auto detect on Server NICs cause such horrible performance for TSM server backups and restores. We have our TSM server NIC set to 100MB Full also our switch Port set to 100 Full but we have users with sorted networks such as 1 GB switches plugged into 100 M wall jacks and travel across several routers., well you get my meaning. These people or demanding to know why they take 8 days to restore 6 GB. They have their server NIC set to Auto detect, They have a 1 GB switch that the server and several others are plugged into because they want hi speed between these servers. But this switch plugs into a normal 100 meg wall jack to get to our data center. I have instructed them to put the NIC to 100 Full and possibly move off swith but they want a technical reason why. They are developers. -- This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
