Throughput Problems on T3 2

[edkaye]

We have purchased 2 PVCs of a T3 line into a Sprint Frame Relay cloud. We have on one end Compaq Prolient ML370 servers running windows 2000 Server and SP4. On the other end is an IBM AIX system (exact model, don't know). We are sending files from the Windows machines to the AIX system. We are using a product called Secure Transport by Valicert. On the Transfer application screen is a speedometer that shows the transfer rate. When we fire up the transfer, we start out a 2,000 KBytes/S but it drops rapidly. We eventually level off around 600 KBytes/S. Much too slow for this environment. If I start up a second machine, it will start at the 2,000 KBytes/S but drop to about 1.4 KBytes/S. The combined speed is getting up to the 2 PVCs worth of bandwidth that we purchased. When one machine ends the transfer, the other machine does not try to pick up the extra capacity. We can not figure out why.

The other problem is why does the speed drop so quickly at the onset of the transmissions. It does not make a difference which machine is started first, they both act the same. Speed drops and never picks up. We set the performance monitor and watched the segments sent/sec value and the machines would start out at 800-1000 seg/sec and then it would drop to 600 seg/sec. A little while later it will drop to 400 seg/sec. The only way to recover some of the speed is to stop the file transmission and restart it. When it restarts, it will try to use the full bandwidth.

We have set the following TCP Registry values in trying to get some consistent throughput.
GlobalMaxTcpWindowSize"=dword:00100000
"TcpMaxDupAcks"=dword:00000065
"SackOpts"=dword:00000001
"Tcp1323Opts"=dword:00000003
"TcpWindowSize"=dword:00018800
We are at a loss of what to do next. Our network guys hooked up a SUN UNIX system to the same network and we fired up all three machines (Sun and 2 Windows Servers) and the SUN system consumed the network at the expense of the Windows systems. One of the Windows systems dropped down to sending only 50 seg/sec and never would recover when the other machines had stopped transmitting.

Any ideas on
a: why the poor performance.
b: why the windows servers will not use the entire bandwidth

 

[cull]

ok, make sure i have this correct. sending FROM the windows box TO the unix box, yes? if that is the case, i hate to say this, but "welcome to windows". windows has a nasty habit of ratcheting down tcp window size and then never ratcheting it back UP when appropriate. i assume unix to unix is just fine? maybe someone else will have more insight, and what i've observed about windows and tcp window size is bunk. but that's sure what *i've* seen :-/

 

[KrisBoutilier]

There is a new bug in the handling of the TCP Window Scaling option as of SP4. I have had the same problem and disabling window scaling using TCP1323Opts=0 or =2 (timestamping only) worked around the issue.

I have been unable to find a Microsoft knowledgebase article on this issue or any relevant hotfixes.

More background available via:

http://groups.google.ca/groups?q=tc...l=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&scoring=d

 

[indianchief]

is the Secure Transport by Valicert also on the SUN Unix system as well when you tested it? If not, could it be that the data encryption process performed by Secure Tranport is taking up processing power from Windows? Just a thought.

 

[ek53]

This turned out to be a problem with MS TCPIP stack. There is a hotfix available from MS. The problem had to do with MS TCP not recognizing that the receiving end window size is changing. When the receiver gets busy, it tells the sending machine to slow down by changing the window size on the TCPIP response message. When the receiver can start taking more data, it will increase the window size. MS TCPP was not adjusting for the increased window size.
This fix was suppose to be in SP4 but did not make it. I had to go to MS SUPPORT (a live person) to get the fix. Thanks for everyones ideas.

 

[TFewkes]

I am in need of this fix and cannot find it in the microsoft hotfix descriptions. When I called microsoft they suggested that I ask you for the hotfix number. If you would provide it I would be very appreciative.
Thanks,
Tim

 

[edkaye]

The information that I received from MS is as follows:
TCP Congestion Window Does Not Return to Optimal Length in Bidirectional WGID:583
ID: 816496.KB.EN-US CREATED: 2003-03-07 MODIFIED: 2003-07-03

http://support.microsoft.com/?id=816496

This patch did fix our performance problems.