I thought I would start a new thread and not clog up the other threads with information/suggestions/etc... I know this problem should be solved on the server side, but it is a bit of a complex issue and may take a while to resolve, and myself like others want to keep on a crunching. :)

This is just my observations and recomendations from working though the connection problems. Further reading can be found in the following threads:

There are a couple work arounds that seem to be working for some people. The simplest one is to use a proxy, the problem is finding one that you can use. I won't recomend any particular one, best to find one that works for you.

For myself I took a differnt route which is working for me. I use Windows 7 and Windows XP on my crunch boxes. What I found is that the default TCP settings for me were not working well for slow links, so I ran the following program to adjust the settings to work better on slow links:

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

Since I have done it on my boxes I have had little trouble downloading and reporting work. Now it's not a 100% fix, but it does allow me to download and report with minimum of fuss.

Just as a side note, I am running on DSL, might be interesting to see what other kinds of services people are using that are having issues.

Average ping time to setiathome.berkeley.edu is 95ms no packet loss
Average ping time to setiboincdata.ssl.berkeley.edu 145ms odd packet loss

Well that is my 0.02 cents for now. I will go back to lurking. :)

EDIT: If anyone else has an suggestions the seem to work for them let us know.

Humm strange, all my caches are full and downlods/uploads for me going fairly well. Downloading an 8mb AP right now @ 25K/s. Most downloads have been around 5K/s. They time out once in a while and on the auto retry they finish most of the time. Have been resisting to push the retry button. :) They have been going not too bad. Now I don't consider it great but it's working.

I found this useful helpful hints post on the number crunching Message Board. I may be violating some protocol, but at the University I often share very useful helpful hints to one or more of my lists. This was posted less than an hour ago. I may try the second solution on one of my boxes. I am also having the same problem with my proxies that Juan mentions. They are not working well at all: Here's the useful post: Thank you cdemers. Brother Frank

Message 1307159 - Posted: 17 Nov 2012 | 20:08:43 UTC
Last modified: 17 Nov 2012 | 20:11:32 UTC
I thought I would start a new thread and not clog up the other threads with information/suggestions/etc... I know this problem should be solved on the server side, but it is a bit of a complex issue and may take a while to resolve, and myself like others want to keep on a crunching. :)

This is just my observations and recomendations from working though the connection problems. Further reading can be found in the following threads:

There are a couple work arounds that seem to be working for some people. The simplest one is to use a proxy, the problem is finding one that you can use. I won't recomend any particular one, best to find one that works for you.

For myself I took a differnt route which is working for me. I use Windows 7 and Windows XP on my crunch boxes. What I found is that the default TCP settings for me were not working well for slow links, so I ran the following program to adjust the settings to work better on slow links:

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

Since I have done it on my boxes I have had little trouble downloading and reporting work. Now it's not a 100% fix, but it does allow me to download and report with minimum of fuss.

Just as a side note, I am running on DSL, might be interesting to see what other kinds of services people are using that are having issues.

Average ping time to setiathome.berkeley.edu is 95ms no packet loss
Average ping time to setiboincdata.ssl.berkeley.edu 145ms odd packet loss

Something needs a really good kicking!
Uploads are working, but I can't report or get any new work for the last couple of days, apart from a couple of freak occasions. I configured a socks proxy, SS5 on my webserver, and that is similarly unreliable.
Curiously boinc on the webserver itself does appear to report results, so I would expect that running the proxy on it would help, but no. Perhaps the scheduler chooses a server based on host id and not its ip address?

I had already noticed that my three Linux pc's hardly have problems reaching the scheduler where two Win7 pc's only manage to reach the scheduler once a day and only when NNT is set. Using a free proxy server worked until the connection to Berkeley was blocked.

I have now configured Apache on one of the Linux pc's to act as a proxy server for the Win7 pc's and this works very well. Both Win7 pc's are filling the cache.

Ok, i've been pinging setiboincdata.ssl.berkeley.edu every few minutes for about half an hour now.
Most of the time i get 50% packet loss. Once or twice it's only been 25%, more often that that though it's 75% packet loss.

Pinging boinc2.ssl.berkely.edu results in anything from 50% to 100% packet loss.
Mostly it's 75% loss, although once (and once only) there was no loss (hosts file set to use .13 server only).

Pinging setiboinc.ssl.berekely.edu results in mostly 50-75% packet loss. Once it was only 25%.

C:\Windows\system32>tracert setiboincdata.ssl.berkeley.edu

Tracing route to setiboincdata.ssl.berkeley.edu [208.68.240.16]
over a maximum of 30 hops:

Pinging on either my windoze or Linux crunches gives similar results - high 200ms plus a fair proportion of drop-outs. Hardly surprising really given they share a common connection!Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

What is the MTU that TCP Opti is recommending? I can set that on my router for all rigs. Currently at 1492.

If you just choose Optimal:
- if the MTU was already set in the registry to 1492 (as was on one of my computers) - TCPOptimizer keeps it for the Optimal values
- if the MTU was not set explicitly in the registry (= Windows default) (as was on another of my computers) - TCPOptimizer sets it to 1500 for the Optimal values

(Which is usually not the proper value for DSL
"MTU/MRU
When the DSL modem sends and receives PPPoE-containing Ethernet frames across the Ethernet link to the router (or PPPoE-speaking single PC), there is an overhead of 8 bytes (2 for PPP, 6 for PPPoE) added within the payload of the Ethernet frame. This added overhead usually means that a reduced limit (so-called ‘MTU’ or ‘MRU’) of 1492 bytes is imposed on the length of IP packets sent or received, as opposed to the usual 1500 bytes for Ethernet networks."http://en.wikipedia.org/wiki/Point-to-point_protocol_over_Ethernet
)

The advice is to make test on particular computer (in MTU/Latency tab click [Largest MTU])
For DSL you will see "You can set your MTU to 1492"
(just check PPPoE on the first tab - MTU 1492 will automatically appear above it)

If someone is unsure - it does not hurt to set MTU to 1492 in any case
(For 'normal' (not DSL) connection you'll lose only 8 bytes of 1500 'performance'
For DSL: 1492 will avoid fragmentation (else if MTU of 1500 is used every single packet will be sent as 2 packets which is big loss))