We were having issues where some PCs had slow upload performance over the WAN. The WAN link was a E3 (34Mbps) with round trip latency of around 50ms and was not congested. When uploading to SharePoint, some PCs would upload at between 150 and 250 KBps. Otherwise identical PCs would upload at over 1MBps. The PCs were running the same physical hardware, the same Operating Systems (Windows XP, although we later reproduced the issue with Windows 7), the same patches and the same drivers. We also confirmed that they had the same TCP settings in HKLM\SYSTEM\CurrentControlSet\Services\TCPIP.
A comparison of packet captures was interesting. The graphic below shows two uploads.
Comparison of two TCP flows
The one on the left is of a slow upload between host “Client” and the SharePoint server “Server”. The one on the right is of a fast upload between host “Client2″ and the SharePoint server “Server”. Both are actually Flow Graphs from Wireshark. Notice that the one on the left pauses after 60ms (0.060 seconds) and waits for an ACK from Server. However, the one on the right continues on. Yet the TCP Window sizes are identical in both flows.
In the end we discovered another parameter in Windows. AFD.SYS is used to support Windows sockets applications. Registry parameters for ADF.SYS are found in HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters. The one that’s relevant is DefaultSendWindow. On the slow machines this parameter was not set and so used the default (decimal 8192 it seems). On the fast PC this was set to decimal 64512 (hex fc00).
Changing this value on the PCs with slow upload speed and then rebooting seems to have fixed the problem.
For more information on this parameter see Network: The relationship between TCPWindowSize and DefaultReceiveWindow.
So, why was this value different between PCs. It seems that when you install the Citrix MetaFrame Client the installer automatically increases this value. The fast PCs all had the MetaFrame Client installed.
Post a Comment