TCP Question - Retransmissions vs. Window SizeTom;

I was following this thread because we were having similar issues with packet 
retransmission that I can not track down. Our server is a Dell with the 
embedded Broadcom card running Suse Linux. I did not see any errors in any of 
the card stats. I did a quick swap of the NIC to an Intel NIC and the response 
time for the application dropped from (45 to 75) seconds to (8 to 12) seconds. 
The only change was the Intel NIC and setting the Intel NIC to the Broadcom IP 
Address. I still see some retransmissions but the recover time and the resend 
is so much faster.

Thanks for the heads up

Dan
  ----- Original Message ----- 
  From: Reynolds, Tom 
  To: wireshark-users@wireshark.org 
  Sent: Friday, December 21, 2007 9:17 AM
  Subject: Re: [Wireshark-users] TCP Question - Retransmissions vs. Window Size


  After troubleshooting similar problems with TCP Retransmissions and TCP Dup 
Acks for 4 weeks! (WireShark was a great tool), we came to the solid conclusion 
that the new Broadcom NICs (HP NC373i) in our new HP DL 380G5 servers were to 
blame.  (this is not isolated to HP, as noted on other forums, some IBM Servers 
with the same card that showed similar problems)  After replacing the Broadcom 
cards with Intel cards (HP NC101T), ALL our networking problems went away.

   

  Check/swap the card type and retest.

   

  
http://forums11.itrc.hp.com/service/forums/bizsupport/questionanswer.do?admit=109447626+1198247493836+28353475&threadId=1153566

   

   

   

  First we noticed really strange upload vs download speed differences.  Oddly 
enough, we could download fairly well, but uploads speeds were horrible.  Then 
after seeing the TCP problems in Wireshark, I started 3 weeks ago researching 
the TCP Window Sizes, TCP1323 options, and all these other TCP setting that are 
configurable in Windows:

   

   

  http://www.speedguide.net/read_articles.php?id=157

   

  SG TCP Optimizer – good tool, didn’t help, but simplified the testing of 
changing the reg keys

  http://www.speedguide.net/downloads.php

   

   

  Slow performance occurs when you copy data to a TCP server by using a Windows 
Sockets API program

  http://support.microsoft.com/default.aspx/kb/823764

   

   

  And if you are using Vista, you have bigger problems.  Do all your testing 
with XP if you still can.  The auto-tuning in Vista caused me to initially 
waste an entire week:

  http://support.microsoft.com/kb/931770

   

   

   

   

  The FTP connection does not use all available bandwidth to download a file in 
Windows Server 2003

  http://support.microsoft.com/kb/891371

  This one talks about modifying the TCPWindowSize reg key.  Tried it, didn’t 
change anything.

   

   

   

  Is your Server 2003 running slow on the network? Check the TCP stack.

  
http://www.devcow.com/weblogs/Is+Your+Server+2003+Running+Slow+On+The+Network++Check+The+TCP+Stack.aspx

   

   

  I had a few more links, but these are the best.  You can search Google for 
them yourself.  Just search for any of the reg keys these articles mention.

   

   

  As I said, after 3 weeks of testing every reg key combination, by luck, I 
tested with a different NIC card, and all my problems went away.

  (as a side note, we did have a few duplex mismatch problems, so ALWAYS hard 
code both the switch and the host. )

   

  Good luck.

   

   

   

   

   

   

   

   

  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Feeny, Michael 
(GWM-CAI)
  Sent: Friday, December 21, 2007 8:52 AM
  To: wireshark-users@wireshark.org
  Subject: [Wireshark-users] TCP Question - Retransmissions vs. Window Size

   

  Hello.

  This may not be a Wireshark question – it is really a TCP question.  To that 
end, if there is a good TCP forum to which I should post this, and similar 
questions, please let me know.

  Recently, there have been 2 occasions where colleagues have seen 
retransmissions occurring, and they have been blaming this on the TCP Window 
Size being too small, and want to increase it.  My response is:

  -       If the TCP Window size was too small, they would see conditions where 
the receiver’s window size goes to zero (or very small), and the sender stops 
sending until a window update is received showing a bigger window size.  They 
are NOT seeing this.

  -       I cannot think of a scenario where a too-small TCP Window size would 
cause retransmissions.  (Can anyone in this forum???)

  Can anyone comment on my assertions?  And, can you point me to a good TCP 
forum?

  Thx much!

  Michael Feeny

  Merrill Lynch


------------------------------------------------------------------------------

  This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically indicated, 
this message is not an offer to sell or a solicitation of any investment 
products or other financial product or service, an official confirmation of any 
transaction, or an official statement of Merrill Lynch. Subject to applicable 
law, Merrill Lynch may monitor, review and retain e-communications (EC) 
traveling through its networks/systems. The laws of the country of each 
sender/recipient may impact the handling of EC, and EC may be archived, 
supervised and produced in countries other than the country in which you are 
located. This message cannot be guaranteed to be secure or error-free. This 
message is subject to terms available at the following link: 
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you 
consent to the foregoing.


------------------------------------------------------------------------------

   



------------------------------------------------------------------------------


  _______________________________________________
  Wireshark-users mailing list
  Wireshark-users@wireshark.org
  http://www.wireshark.org/mailman/listinfo/wireshark-users
_______________________________________________
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

Reply via email to