["Reynolds, Tom" <Tom.Reynolds@xxxxxxx>]

Title: 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: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Feeny, Michael (GWM-CAI)
Sent: Friday, December 21, 2007 8:52 AM
To: wireshark-users@xxxxxxxxxxxxx
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.

---