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:

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.

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!

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

"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.

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.

"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.

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

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