I normally wouldn't do this, but I attached 2 of the systems to Einstein, and there is no problem getting work, and the application files etc. I can only conclude that Berkeley has some kind of issue that I can't resolve from this end. I thank those that gave information to help me with this, a lot of what is misunderstood I believe, is that the software requires a lot of patience, while it tries to correct issues by itself. With Classic, there were a number of things that could be done to affect an issue, and the results were by far more immediate.

So, the question becomes "what is the difference between SETI and Einstein?"

... and also, what isn't (BOINC handles all communications, for both projects).

The problem is that your problem is not well understood. Most of us aren't having trouble. Those who do usually have some projects that work without error, and others that are really difficult.

I looked to a different source for application and data. If I saw the problem still, I would have reformatted, and reinstalled XP from scratch next. But no problem, it all went just fine. This was just to prove that my systems are functional.
Here is what I get from Seti:

1/14/2006 3:23:34 PM 363 Temporarily failed download of 04se04aa.570.31584.28414.1.210: system I/O

1/14/2006 9:07:56 PM 368 Temporarily failed download of 04se04aa.570.31584.28414.1.210: error 500


Just a generic guess: Einstein probably does not have nearly the same amount of overall traffic to contend with. Berkeley had some disk issues that may have ended up corrupting small batches of files (like the ones que'd for me). Have you ever installed software, only to have it not behave, have to deinstall it, and then reinstall it before it starts working? Also, I have dial up, not broadband, so the problem would be probably more evident for me, as I notice them because I have "attended" uploads and downloads. I am not placing "blame" anywhere, this will probably get worked out somehow.I was just wondering if anyone had run into the problem and resolved it yet. I have 4 systems that behave, and 3 that do not, since the last outage. Prior to the last outage, the only difficulty I have had was when the servers were unavailable. (Like on Wednesdays for a few hours). I have tried all sorts of things to specific systems to attempt to make them functional for Seti. After about a week now, I tried attaching to Einstein, no problems with that, so I have to assume that the problem I am seeing is some kind of kink in communication / bad files / etc. that I just have to wait for the system in Berkeley to discover and eliminate. I dropped from about 800 RAC to around 500, I hope to get those figures back on track soon.
http://www.speedguide.net/analyzer.php?DATA_OFFSET=40&TCP_Options_string=020405b40103030001010402&IP_MTU_DISCOVER=1&WIN=25728&RWIN=25728&MSS=1460&SCALE=0&TTL=53&TSOPT=0&SACK_PERM=1&IP_TOS=0&IP=4.157.23.161&timestamp=1137293217

The above URL will display your TCP/IP properties, here is what it says about my dial up:

TCP options string = 020405b40103030001010402
MTU = 1500
MTU is fully optimized for broadband.
MSS = 1460
Maximum useful data in each packet = 1460, which equals MSS.
Default Receive Window (RWIN) = 25728
RWIN Scaling (RFC1323) = 0 bits
Unscaled Receive Window = 25728

For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
513920 (MSS x 44 * scale factor of 8)
256960 (MSS x 44 * scale factor of 4)
128480 (MSS x 44 * scale factor of 2)
64240 (MSS x 44)
bandwidth * delay product (Note this is not a speed test):

Your RcvWindow limits you to: 1029.12 kbps (128.64 KBytes/s) @ 200ms
Your RcvWindow limits you to: 411.648 kbps (51.456 KBytes/s) @ 500ms
MTU Discovery (RFC1191) = ON
Time to live left = 53 hops

TTL value is ok.
Timestamps (RFC1323) = OFF
Selective Acknowledgements (RFC2018) = ON
IP type of service field (RFC1349) = 00000000 (0)

I don't know if this is useful or not to anyone.

Forgot to mention, there is no error 500 in the new version. It has been replaced by "Redirects hit maximum amount"

---

I'm not sure I have the technical know-how - but I think I have a similar problem to this. BOINC Manager is reporting:

Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
Requesting 0 seconds of work, returning 0 results
Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed
No schedulers responded
Deferring communication with project for 58 seconds

BOINC has being doing this since it uploaded my last work unit. Since I can't get any work from SETI, I tried climate prediction - and that is working fine. Can anyone help me get work from SETI again?!

Apologies if this is a different issue, but it sounds similar to me.

Thanks

---

Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
Requesting 0 seconds of work, returning 0 results

Different issue; this is saying that for whatever reason (debt to other project most likely), the scheduler does not WANT work.

Also, I have dial up, not broadband,


MTU = 1500
MTU is fully optimized for broadband.

Did you miss something here?
Your system is configured for broadband,
yet you say you have and use Dial-up.
For a dial-up connection you normally want
an MTU= 576 value.
That could be a problem for you if set wrong.
Also a MTU= 576 should get you past any Black hole routers.
You may want to try setting MTU to 576 and see if that helps.

From the code:

CURLE_TOO_MANY_REDIRECTS , /* 47 - catch endless re-direct loops */

I'm getting different problems, just over the last 4 hours.

15/01/2006 14:08:06||Couldn't connect to hostname [setiboinc.ssl.berkeley.edu]
15/01/2006 14:08:10|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -106
15/01/2006 14:08:10|SETI@home|No schedulers responded
15/01/2006 14:09:33||Couldn't connect to hostname [setiboinc.ssl.berkeley.edu]
15/01/2006 14:09:36|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -106
15/01/2006 14:09:36|SETI@home|No schedulers responded
15/01/2006 14:11:12|SETI@home|No work from project
15/01/2006 14:21:42||Couldn't connect to hostname [setiboinc.ssl.berkeley.edu]
15/01/2006 14:21:47|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -106
15/01/2006 14:21:47|SETI@home|No schedulers responded
15/01/2006 14:23:10||Couldn't connect to hostname [setiboinc.ssl.berkeley.edu]
15/01/2006 14:23:13|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -106
15/01/2006 14:23:13|SETI@home|No schedulers responded
15/01/2006 14:26:16|SETI@home|No work from project
15/01/2006 14:36:46||Couldn't connect to hostname [setiboinc.ssl.berkeley.edu]
15/01/2006 14:36:50|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -106
15/01/2006 14:36:50|SETI@home|No schedulers responded
15/01/2006 14:46:34|SETI@home|No work from project
15/01/2006 15:20:33|SETI@home|No work from project
15/01/2006 16:41:28||Couldn't connect to hostname [setiboinc.ssl.berkeley.edu]
15/01/2006 16:41:32|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -106
15/01/2006 16:41:32|SETI@home|No schedulers responded
15/01/2006 17:02:43|SETI@home|No work from project
15/01/2006 17:03:43|SETI@home|Fetching master file
15/01/2006 17:04:13|SETI@home|No work from project
15/01/2006 17:14:45||Couldn't connect to hostname [setiboinc.ssl.berkeley.edu]
15/01/2006 17:14:49|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -106
15/01/2006 17:14:49|SETI@home|No schedulers responded
15/01/2006 17:16:10||Couldn't connect to hostname [setiboinc.ssl.berkeley.edu]
15/01/2006 17:16:14|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -106
15/01/2006 17:16:14|SETI@home|No schedulers responded
15/01/2006 17:17:44|SETI@home|No work from project
15/01/2006 17:28:17||Couldn't connect to hostname [setiboinc.ssl.berkeley.edu]
15/01/2006 17:28:20|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -106
15/01/2006 17:28:20|SETI@home|No schedulers responded
15/01/2006 17:30:05|SETI@home|No work from project
15/01/2006 17:40:50|SETI@home|No work from project
15/01/2006 17:54:48||Couldn't connect to hostname [setiboinc.ssl.berkeley.edu]
15/01/2006 17:54:51|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -106
15/01/2006 17:54:51|SETI@home|No schedulers responded
15/01/2006 17:57:00||Couldn't connect to hostname [setiboinc.ssl.berkeley.edu]
15/01/2006 17:57:02|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -106
15/01/2006 17:57:02|SETI@home|No schedulers responded

Prior to the intial compaction of the database a week or 2 back (where the whole thing was slowly grinding to a halt) i was getting these regularly. Since that outage, till 4 hours ago, i'd been able to connect without any problems at all.

---

Grant
Darwin NT

Ok, the forums are a slow as a wet week & i just checked the Server Status page- other than the current result creation rate, nothing's been updated for 3 hours. And just having a look at the network traffic shows it's gone from it's usual 40Mb/s down to 320kb/s (and it looks like it may still be falling).
So i guess something somewhere is not working as it should.

---

Grant
Darwin NT

number of redirects hit maximum amount

(From a test build of BOINC with ERROR 500 fixes
and the new error message code.)

This error message comes from the LibcURL.DLL
used with the new versions of BOINC.


From cURL code:

CURLE_TOO_MANY_REDIRECTS , /* 47 - catch endless re-direct loops */

case CURLE_TOO_MANY_REDIRECTS :
return "number of redirects hit maximum amount";


From cURL setup:

MAXREDIRS n
Number curl_easy_setopt(curl, CURLOPT_MAXREDIRS, n): Pass a long.
The set number will be the redirection limit.
If that many redirections have been followed,
the next redirect will cause an error (CURLE_TOO_MANY_REDIRECTS).


From cURL error codes:

CURLE_TOO_MANY_REDIRECTS (47)

Too many redirects.
When following redirects, libcurl hit the maximum amount.
Set your limit with CURLOPT_MAXREDIRS.


Looking through the cURL documentation and the list of known problems
with the current stable version 7.15.1 (Dec.2005) there are several
known problems with SOCKS PROXY and connection timing problems with Proxy's
in general. There seemed to be comments that SOCKS Proxy is not yet supported
by LibcURL yet.

The current version of LibcURL shipped with BOINC is version 7.14.0.0
so there is at least a newer version of this critical software used for
making and handling connections with the Project servers.


Theory one: Many users having connection problems (error 500) are using a SOCKS Proxy.

Theory two: Some users have their own local proxy server and are trying to reach the Berkeley servers through yet another proxy server to solve "other" Internet problems, and the MaxRedirs setting is too low to allow this to work.

Theory three: The LibcURL software still has too many problems to be used in a complex world wide network for connecting to a high volume server. And may be the source of some of the ERROR 500 problems.


Recommendation one: Don't use a SOCKS PROXY.

Recommendation two: Don't try to go through two proxy's.

Recommendation three: Punt this one back to the Berkeley Staff for review and solutions, as this is a little bit over my head, and not much more I can do about it anyway.


For those that like to live on the bleeding edge of experimentation, try replacing your current LibcURL.DLL version 7.14.0.0 with a version 7.15.1 build suitable for your OS, and then restart and see what happens. If it solves ALL of your problems, let someone know.

Also, I have dial up, not broadband,


MTU = 1500
MTU is fully optimized for broadband.

Did you miss something here?
Your system is configured for broadband,
yet you say you have and use Dial-up.
For a dial-up connection you normally want
an MTU= 576 value.
That could be a problem for you if set wrong.
Also a MTU= 576 should get you past any Black hole routers.
You may want to try setting MTU to 576 and see if that helps.

Ok, changed it. So far, no difference, other than transfers take a little longer. Some days 19.2 is a good connection. But even at that rate, I never had any problems until recently.

---

number of redirects hit maximum amount

(From a test build of BOINC with ERROR 500 fixes
and the new error message code.)

This error message comes from the LibcURL.DLL
used with the new versions of BOINC.


From cURL code:

CURLE_TOO_MANY_REDIRECTS , /* 47 - catch endless re-direct loops */

case CURLE_TOO_MANY_REDIRECTS :
return "number of redirects hit maximum amount";


From cURL setup:

MAXREDIRS n
Number curl_easy_setopt(curl, CURLOPT_MAXREDIRS, n): Pass a long.
The set number will be the redirection limit.
If that many redirections have been followed,
the next redirect will cause an error (CURLE_TOO_MANY_REDIRECTS).


From cURL error codes:

CURLE_TOO_MANY_REDIRECTS (47)

Too many redirects.
When following redirects, libcurl hit the maximum amount.
Set your limit with CURLOPT_MAXREDIRS.


Looking through the cURL documentation and the list of known problems
with the current stable version 7.15.1 (Dec.2005) there are several
known problems with SOCKS PROXY and connection timing problems with Proxy's
in general. There seemed to be comments that SOCKS Proxy is not yet supported
by LibcURL yet.

The current version of LibcURL shipped with BOINC is version 7.14.0.0
so there is at least a newer version of this critical software used for
making and handling connections with the Project servers.


Theory one: Many users having connection problems (error 500) are using a SOCKS Proxy.

Theory two: Some users have their own local proxy server and are trying to reach the Berkeley servers through yet another proxy server to solve "other" Internet problems, and the MaxRedirs setting is too low to allow this to work.

Theory three: The LibcURL software still has too many problems to be used in a complex world wide network for connecting to a high volume server. And may be the source of some of the ERROR 500 problems.


Recommendation one: Don't use a SOCKS PROXY.

Recommendation two: Don't try to go through two proxy's.

Recommendation three: Punt this one back to the Berkeley Staff for review and solutions, as this is a little bit over my head, and not much more I can do about it anyway.


For those that like to live on the bleeding edge of experimentation, try replacing your current LibcURL.DLL version 7.14.0.0 with a version 7.15.1 build suitable for your OS, and then restart and see what happens. If it solves ALL of your problems, let someone know.

The non-SSL version of 7.15? I tried both, the ssl version gave me an error regarding another DLL that I couldn't find. The non-SSL version works the same as 7.14 (error 500). I use the Analog-X proxy, HTTP, not Socks. I use the standard URL for Berkeley, I haven't tried any of the proxies available yet.

---

The non-SSL version of 7.15? I tried both, the ssl version gave me an error regarding another DLL that I couldn't find. The non-SSL version works the same as 7.14 (error 500). I use the Analog-X proxy, HTTP, not Socks. I use the standard URL for Berkeley, I haven't tried any of the proxies available yet.

That was worth a try.

I did not find the list of changes that went into 7.15.1 so I had no idea if it would help. In your case at least, it did not help. From what I did find, the HTTP proxy should be working OK, and there are indications of connection problems with SOCKS Proxy. At least the actual error message for your ERROR 500 and what code is generating it should help someone isolate what your problem is. It may not have anything to do with proxy servers at all, as I said I have to punt here.

The non-SSL version of 7.15? I tried both, the ssl version gave me an error regarding another DLL that I couldn't find. The non-SSL version works the same as 7.14 (error 500). I use the Analog-X proxy, HTTP, not Socks. I use the standard URL for Berkeley, I haven't tried any of the proxies available yet.

That was worth a try.

I did not find the list of changes that went into 7.15.1 so I had no idea if it would help. In your case at least, it did not help. From what I did find, the HTTP proxy should be working OK, and there are indications of connection problems with SOCKS Proxy. At least the actual error message for your ERROR 500 and what code is generating it should help someone isolate what your problem is. It may not have anything to do with proxy servers at all, as I said I have to punt here.

If I can make sense of any type of changes to try, I'll give it a go. I will hang in as long as it takes, I feel that it's worth it.

---

The non-SSL version of 7.15? I tried both, the ssl version gave me an error regarding another DLL that I couldn't find. The non-SSL version works the same as 7.14 (error 500). I use the Analog-X proxy, HTTP, not Socks. I use the standard URL for Berkeley, I haven't tried any of the proxies available yet.

That was worth a try.

I did not find the list of changes that went into 7.15.1 so I had no idea if it would help. In your case at least, it did not help. From what I did find, the HTTP proxy should be working OK, and there are indications of connection problems with SOCKS Proxy. At least the actual error message for your ERROR 500 and what code is generating it should help someone isolate what your problem is. It may not have anything to do with proxy servers at all, as I said I have to punt here.

If I can make sense of any type of changes to try, I'll give it a go. I will hang in as long as it takes, I feel that it's worth it.

I am now starting to get "time out", "system i/o", "can't connect" messages along with the "500" errors I was getting. It has also started to grow to include all of my systems. It is random, some get through sometimes, and some of it occurs with downloads, and now some occur with uploads. Einstein however, remains fuctional in both uploads and downloads. I believe now that it is weather related, as the bits and bytes from Berkeley probably do not want to travel through wires that are around 50 degrees colder, dripping with freezing rain. :>

---

I am now starting to get "time out", "system i/o", "can't connect" messages along with the "500" errors I was getting. It has also started to grow to include all of my systems.

Just before you posted, it looks like they did something in the Seti Lab that shut off upload/download for awhile, so those additional errors might just be normal. Seems to be coming back up. But someone is in there changing things.

I am now starting to get "time out", "system i/o", "can't connect" messages along with the "500" errors I was getting. It has also started to grow to include all of my systems.

Just before you posted, it looks like they did something in the Seti Lab that shut off upload/download for awhile, so those additional errors might just be normal. Seems to be coming back up. But someone is in there changing things.

I took one system and did a "Detach" from Seti. Got "Attached" succesfully. But now it gives "No Start Tag in Scheduler Reply" and "Can't Parse Scheduler Reply". After 12 minutes, it came back with "No work from project".
I "Attached" to Einstein, within 5 seconds, I have the application, support files and work downloading. If the problem is on this end, I can't concieve of a way to test that concept other than what I have already done.

---

Not sure how related this is but i've been getting the 500 error on two machines attached to boincsimap. They were failing when trying to upload the results.

I got a little desperate when i had 30+ results to return and decided to go rooting through the BOINC directory to see if i could see any problems.

First i noticed "master_boinc.bio.wzw.tum.de_boincsimap.xml" was incorrectly formatted on one machine and blank on the other, so i copied over the file from a working machine.

I then noticed "sched_request_boinc.bio.wzw.tum.de_boincsimap.xml" was also blank on both machines, this file i just deleted.

I told both machines to update and they uploaded all my finished work units and are both updating / contacting the server happily now.

As i said this was on Boincsimap but i'm curious as to wether this may help with problems people are having on SETI.

Edit: *sigh* to good to be true one of them just went down again =/

---

Not sure how related this is but i've been getting the 500 error on two machines attached to boincsimap. They were failing when trying to upload the results.

I got a little desperate when i had 30+ results to return and decided to go rooting through the BOINC directory to see if i could see any problems.

First i noticed "master_boinc.bio.wzw.tum.de_boincsimap.xml" was incorrectly formatted on one machine and blank on the other, so i copied over the file from a working machine.

I then noticed "sched_request_boinc.bio.wzw.tum.de_boincsimap.xml" was also blank on both machines, this file i just deleted.

I told both machines to update and they uploaded all my finished work units and are both updating / contacting the server happily now.

As i said this was on Boincsimap but i'm curious as to wether this may help with problems people are having on SETI.

Edit: *sigh* to good to be true one of them just went down again =/

I took a look, all of mine seem to be the same, including the byte count of the file. Same for the other projects I am in. This only happened recently, with the last outage, I had changed nothing here, and had no problems up until that time. There were no events that altered the 3 systems, in 2 different buildings that are exhibiting this phenomenon.

---

BOINC normally works through the firewall, i just bypassed the firewall completely and everything started working.

---

BOINC normally works through the firewall, i just bypassed the firewall completely and everything started working.

All of mine go through the same firewall, all can connect to the internet, I just have 3 that will not talk to Seti properly, but will talk fine to Einstien.

---

I took a look, all of mine seem to be the same, including the byte count of the file.

I am sorry to have to ask, but leaving out details can slow the process down quite a bit. What exactly were the size of those files. And when viewed in Wordpad, did the XML look valid or was there garbage characters at the front or end of the file.

Your symptoms indicate that the files might be damaged or having missing parts to it. But no idea why it works on one and not the other system.

A corrupted, zero length or missing master_project.XML would sure cause a lot of problems trying to connect to that projects Scheduler, as it contains the URL for that projects scheduler!

For Seti, the master_setiathome.berkeley.edu.xml should be 69 bytes long, and contain the URL of <scheduler>http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi</scheduler> or else you are never going to get a response from the server. And with the current error messages, that would result in an ERROR 500. Or no response from te scheduler.