Observations after affecting process described in cdemers post.

Download speeds appear to be similar to the proxy that I was generally using, around 5-10kB/s, so no apparent significant improvement there. What I have noticed is that the downloads start quicker, they sometimes have a tendency to burst in the first 5-15% of the download with speeds in the range 15-20kB/s, they don't seem to stall as often (in fact, hardly ever), and if downloads do hesitate, the hesitation is not for long. Overall, I think the outcome is positive and have modified all my machines accordingly.

BTW, in comparison to not using a proxy, hugely beneficial and well worth doing.

cdemers, in line with T.A., +1

Lionel

---

This is the first morning in a long while when checking Boinc Tasks there are no stalled DL's across 6 machines!!

I will be interested to see what happens after the weekly outage!

---

[...] 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

[...]

Interesting find. Upon investigating my machines, I found that my Win7-Ultimate already had the setting in place; and it had not had any d/l issues. My Win8-Pro machine was missing the setting, though it had not seen any SETI work yet... I did not have an issue with my WiFi being used to d/l either. See ya all at the challenge.

---

Just a followup note, if anyone is seeing any slowdown of their network, check the ECN setting in TCPOptimizer. Seems that the default of some network cards is to enable this feature, which will have the effect of slowing down your communications. Just make sure ECN is set to DISABLED if you have this issue.

http://en.wikipedia.org/wiki/Explicit_Congestion_Notification

---

I like this setting!

I reran TCP-Optimizer and found that the optimal settings only had Window Scaling selected, so I enabled Timestamps, saved and rebooted.

I was amazed at what a difference it made. I have been running this new setting for over 30 hours now, and have only had 2 downloads stall, and they finished on the first retry. This is great!

The Timestamps must be the secret bit that makes proxy servers work for people.

Thank you for this excellent tip.

---

Bruce

Just a followup note, if anyone is seeing any slowdown of their network, check the ECN setting in TCPOptimizer. Seems that the default of some network cards is to enable this feature, which will have the effect of slowing down your communications. Just make sure ECN is set to DISABLED if you have this issue.

http://en.wikipedia.org/wiki/Explicit_Congestion_Notification

It probably depends on the version of TCP Optimizer you have to hand.

It's unfortunate that the guidance notes on http://www.speedguide.net/tcpoptimizer.php haven't been updated since version 2 and Windows XP - ECN isn't even visible on the explanatory screenshots.

But there is a small note at the very bottom:

TCP Optimizer v. 3.0.7 (03.22.2011):

● Changed ECN Capability optimal recommendation in General tab based on user feedback and issues with some US ISPs

Sounds like you shouldn't use v3.0.6 or before.

Not a single download error since using TCP Optimzer and checking the Timestamps box. Thanks for the info!

---

The Universe is not only stranger than you imagine, it's stranger than you can imagine.

SETI@home classic workunits 1,405 CPU time 57,318 hours

Excellent work cdemers. I owe you a beer.
I'm sure the rest of the community could stand
you a few rounds also.

Excellent work cdemers. I owe you a beer.
I'm sure the rest of the community could stand
you a few rounds also.

+1
I'll buy into that. Working great for 24+ hours.

Just 2 questions:
1) Has anyone seen problems with other network activity?
2) What's a keyboard attendant supposed to do now since I don't have to man the retry button?

---

Another Fred
Support SETI@home when you search the Web with GoodSearch or shop online with GoodShop.

Excellent work cdemers. I owe you a beer.
I'm sure the rest of the community could stand
you a few rounds also.

+1
I'll buy into that. Working great for 24+ hours.

Just 2 questions:
1) Has anyone seen problems with other network activity?
2) What's a keyboard attendant supposed to do now since I don't have to man the retry button?

1) None here, though I'm watching. I did a very heavy Einstein download (well over 100 data files) while SETI was downloading too. Both worked fine together.
2) Drink beer.

Another +1. Never seen dl's come through that fast before.

---

2) Drink beer.

I´m drinking to celebrate too, finaly someone find the light at the end of the tunnel!

All DL working fine, not even need the retry cmd.

---

Works a treat

---

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

All I did was add that single value to the windows registry, and all of a sudden all my downloads complete without errors, and at about 6 KBps.

Incredible!!

---

I just wonder how big an impact this might make
on freeing up bandwidth?

I notice that the Panic thread hasn't been posted to in a day. Maybe because everyone (who posts) has tried this.

---

The Universe is not only stranger than you imagine, it's stranger than you can imagine.

SETI@home classic workunits 1,405 CPU time 57,318 hours

I don't know if anybody else is seeing this but since the fix came out my backlog of pendings has been climbing. And my RAC has deteriorated a little when it should be climbing. I would have thought the opposite but perhaps what I'm seeing is a new population of turnaround times being superimposed on the old one. I'd guess a lot of the faster nodes have applied the fix and there is a new faster-turnaround bump building up in the distribution of result run times and that bump is still forming.

In other words the fast machines are right now busy processing more work and haven't yet stabilized the rate at which they report back.

Or...could just be a random thing. RAC always takes a little upfront hit when long-run jobs come out and I have more than the normal amount of AP.

Or...could just be thinking too much cuz there's nothing else to do.

Oh My God! Running TCP Optimizer, clicking on Custom, then clicking Window Scaling AND Timestamps, made my SETI downloads fly! After weeks of clicking and reclicking the "retry Now" button on BOINC, to try and get some SETI work for my hungry machines, this worked wonders for me. Don't know how to pass this on, but if someone knows how, please let the SETI world know. Thanks to everyone who figured this out. Regards, Rick

---

I don't know if anybody else is seeing this but since the fix came out my backlog of pendings has been climbing. And my RAC has deteriorated a little when it should be climbing. I would have thought the opposite but perhaps what I'm seeing is a new population of turnaround times being superimposed on the old one. I'd guess a lot of the faster nodes have applied the fix and there is a new faster-turnaround bump building up in the distribution of result run times and that bump is still forming.

In other words the fast machines are right now busy processing more work and haven't yet stabilized the rate at which they report back.

Or...could just be a random thing. RAC always takes a little upfront hit when long-run jobs come out and I have more than the normal amount of AP.

Or...could just be thinking too much cuz there's nothing else to do.

I would say you would need to wait a week or so before attributing ANY fluctuation in RAC to this. RAC is not an instant yardstick and of course there is no way of knowing the total number of machines that have had this setting applied.

---

I would say you would need to wait a week or so before attributing ANY fluctuation in RAC to this. RAC is not an instant yardstick and of course there is no way of knowing the total number of machines that have had this setting applied.

This thread has been read 1200+ times. That's an incredibly small number of machines for this project.

---

The Universe is not only stranger than you imagine, it's stranger than you can imagine.

SETI@home classic workunits 1,405 CPU time 57,318 hours