This is a follow up to:

http://setiathome.berkeley.edu/forum_thread.php?id=70066

Thanks to Tom for getting me to look back into this. I had switched to a local unix proxy on my router to fix this problem, now after a follow up suggestion from Tom this seems to be working well. Noticed though that you should write down the settings before switching to optimal, as it does not always use the optimal settings.

This has been tested on both Windows XP and Windows 7 machines.

Recap from my last post:

You will need to download the following program to help makes the changes to windows networking:

TCP Optimizer - Info about the program:
http://www.speedguide.net/tcpoptimizer.php

Where to download it from:
http://www.speedguide.net/downloads.php

I would only recomend this to anyone that is comfortable with doing this. It makes changes to your windows registry. As with any program like this you should take precautions.

Run the program as Administrator, select the Optimize button at the bottom, then apply. It will show you what it is going to change and press OK.

After that for the settings to become active you need to reboot your computer.

After you have rebooted, run the program again as administrator. Now you may need to make note of what the current settings are set to. Select CUSTOM, now double check that everything hasn't changed anywhere. If so correct the settings back to what the optimal set them to.

Now for the changes to what the Optimal settings configured, there is a box in the bottom right hand corrner that says TCP 1323 Options, check both options Window Scaling and Timestamps. Apply those settings and reboot again.

Once booted up again, would be good to just double check that everyting stayed correctly, run the program one more time and make sure everything looks right to what you wrote down and the options in the box are checked. If all is fine, just click the exit button and don't change anything.

Note don't change any other settings in the program unless you really know what you are doing. I'm just trying to keep this as simple as possible.

Information abour RFC1323:
http://www.ietf.org/rfc/rfc1323.txt

Additional information:
http://en.wikipedia.org/wiki/TCP_tuning

---

Thank you very much!

It seems that the TCP 1323 really did the trick.
Ive been running some of my hosts with the optimized values for a while and Ive not noticed any difference, but after changing this 1323 options the download speed went from less than 1Kbit to more than 5... and even when 5Kbit is not an amazing speed, it's still 5 times better than before!

Just one detail, on Win Vista, the TCP optimizer app was not able to keep some settings as they were set by the optimal option, no matter how many times I've retried some of the values allways went back to what they were before rebooting, they didnt stayed even setting them manually...
But, the TCP 1323 options stayed and they improoved the transfers speeds anyway.

---

That's good to hear, I don't have any Vista machines around to test with. The XP machine would keep defaulting different settings than the optimal. But it let me re type all the optimal settings back in. Strange that Vista also behaves strange in that reguard. Glad to hear that it is helping for you.

---

I think that some settings are stored in a different way on Vista or something alike... But anyway it seems that the changes needed to make it work are preserved.

By the way, not only the speed has increased, since Ive changed the settings Ive not found any record in the event logs of all my SETI hosts about a file transfer failure... Ive not seen this since, ermm..., never!

---

Works perfect, no file transfer failures in any of my hosts (3 diferent ISP) after i change the settings. I use TCP Optimizer before but just with optimal settings.

I almost can´t belive this simple change in the settings could be the answer to all of our headaches of the last 6 months.

Thanks for the tip.

---

Tom asked me to test this idea too, and it really does seem to do the trick.

More importantly, it explains all the anomalous behaviour we've been seeing - why proxies work, and why Mac/Linux clients get good downloads, when Windows machines are crawling.

The crucial change is to enable TCP timestamps and window scaling, as provided for in RFC 1323. Mac/Linux machines have these enabled by default, and I suspect most public proxies are Linux-based.

Windows - all versions since at least Windows 2000 - have the capability built in, but it has to be enabled manually. This requires a new value to be added to the registry, which is all the TCP Optimiser does to enable RFC1323 - the details are in the Microsoft Technet article on Tcp1323Opts. For those who prefer to manage their machines themselves, the setting to make is

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]
"Tcp1323Opts"=dword:00000003

While we're here, let's repeat the other worthwhile optimisation we found last time:

netsh interface ipv4 set subinterface "Local Area Connection" mtu=1476 store=persistent

"Check that your computer uses the default name of "Local Area Connection" for your internet connection - I suspect that may not be true for WiFi or USB modem/dongle connections."

Tom asked me last night to run this past Matt and Eric before we go overboard with the publicity, but Murphy's law struck - my email got mangled in transmission (their problem, I think - a copy recipient got it properly). I'm still waiting for a reply to the second attempt.

But since the fix is standards-based, and has has a proper technical underpinning, I don't think there's any problem with starting to discuss it now. In the next day or two (I'm a bit busy today), I'll try and get a proper sticky post organised with all the details and links.

To add a bit more info.

I have recently set up Freeproxy on my Windows Home Server, but was unable to see any benefits from any of my machines.

Having seen this thread I ran TCP optimizer on my Windows Home Server, and set window scaling and TCP timestamp.

I also had a cruncher that had NNT set as I was going preparing to switch it off for a while.

So I allowed it to down load tasks. Well to say I was surprised it putting it mildly. It has just downloaded 106 tasks without a pause at speeds between 2 and 10k and around 50-60 second per wu.

I haven't seen anything like that for a while and this is with the TCP Optimzer on the Windows Proxy not the client!!

It would certainly seem that TCP timestamps and window scaling have an effect.!!

---

I can report I got clean downloads overnight as well with these settings. For the first time in memory!

I have tried the optimized settings before with RFC1323 scaling but without timestamps. That one parameter appears to be the magic.

We'll see how it holds up in the days to come. But congratulations Bernie, well done.

I wonder how much wasted bandwidth by failed TCP connections this might save. All those retrys by tens of thousands of hosts has to be clogging the pipes somewhat. Would be good to maybe rewrite it a bit better and make it a stickie.

---

I wonder how much wasted bandwidth by failed TCP connections this might save. All those retrys by tens of thousands of hosts has to be clogging the pipes somewhat. Would be good to maybe rewrite it a bit better and make it a stickie.

Richard Hasselgrove is proposing exactly that, to make a sticky. See above.

Correction, I may have said congrats to Bernie, should have been directed toward you cdemers. Of course congratulations to Bernie too for the mad downloads.

I´m using Tcp Optimizer a long time but to enable the Timestamp option helped really.
I´ve downloaded the complete Project files inclusive 1 ap work in 30minutes.
Downloadspeed was constantly at 6-7 Kbps without any connection breaks.
With that option the Servers should´nt be so stressed and the network overhead should go down.So the more Windows user are fixing that the more bandwith is free for downloading work.

Thx

While we're here, let's repeat the other worthwhile optimisation we found last time:

netsh interface ipv4 set subinterface "Local Area Connection" mtu=1476 store=persistent

"Check that your computer uses the default name of "Local Area Connection" for your internet connection - I suspect that may not be true for WiFi or USB modem/dongle connections."

If you are going to include this in the stiky, then you can be sure that the name of the default connection needs to be checked as it changes when there is more than one lan adapter and also the default names are always translated to the language of the OS.

In the next day or two (I'm a bit busy today), I'll try and get a proper sticky post organised with all the details and links.

If this keeps working for everybody here, and knowing that there are a lot of crunchers out there that dont read the forums, may be is a good idea to broadcast the link to the stiky in the news... (something like "if your windows computers have issues dowloading tasks please visit this thread to learn how to fix it"...) And also, I think that the same sticky should be posted in the Q&A forum.

---

Works perfect.

Great work guys.

Tim

---

Windows - all versions since at least Windows 2000 - have the capability built in, but it has to be enabled manually. This requires a new value to be added to the registry, which is all the TCP Optimiser does to enable RFC1323 - the details are in the Microsoft Technet article on Tcp1323Opts. For those who prefer to manage their machines themselves, the setting to make is

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]
"Tcp1323Opts"=dword:00000003

While we're here, let's repeat the other worthwhile optimisation we found last time:

Do I need to reboot after adding that to the registry (on WinXP and Win7)?

---

Windows - all versions since at least Windows 2000 - have the capability built in, but it has to be enabled manually. This requires a new value to be added to the registry, which is all the TCP Optimiser does to enable RFC1323 - the details are in the Microsoft Technet article on Tcp1323Opts. For those who prefer to manage their machines themselves, the setting to make is

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]
"Tcp1323Opts"=dword:00000003

Do I need to reboot after adding that to the registry (on WinXP and Win7)?

Yes, I think you do.

Always reboot when you make changes to the registry for the changes to take effect.

Tim

---

OK, thanks.

---

Works perfect.

Great work guys.

Tim

+1

44 units downloaded in 6 minutes after setting as per cdemers first post.

T.A.

I have just had the unexplainable pleasure of watching 4 simultaneous AP WU DL's run from start to finish without interruption.

I have done many changes to my settings, more simultaneous DL's, running a program to restart stopped DL's every 15 minutes, changing timeout settings, and many other small things.

To think that this relatively small change (timestamps (scaling was allready turned on)), would do such a difference...

I kept an eye on the DL's, and watched some allmost sure signs of a failed DL (pause for 5-10 seconds), just to see the DL's continue. Fantastic!

Thank you to the guys who found this fix :)

---

41 MB's in 6 minutes, no hangs - unprecedented on this pc. You guys are beyootiful - thanks!

---