For the last day I have constantly getting...

|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of 500

Same old problem again. Why is it that immediately after the outages I was able to upload and contact the schedular with no real problems, but now that the traffic has slowed down I'm seeing this failure again?

Live long and crunch.

---

Paul
(S@H1 8888)
And proud of it!

Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of 500

Paul, which one of your computers has that problem? Or is it all of them?

What version is giving that error?

James :-)

For the last day I have constantly getting...

|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of 500

I frequently get timeouts (on every 3rd, 4th or 5th request) where the scheduler doesn't respond but no error 500.
This happens to all my 3 computers, 2 using 4.45 and 1 using 4.19.

Does this error 500 also have to do sth with these timeouts?


Greetings from Luxembourg,

Georges

---

Paul, could I ask if you are trying to force a connection using project update? I've seen this when I (dial up user) try to force two projects to connect at the same time, OR if seti had made a request earlier(that I knew nothing about) and then I tried to force a connection to seti or beta or ppah, etc.

tony

I have taken to only sending one project in at a time and then waiting until each one is completely finished before trying the next one. Also, I notice ppah will download some then wait, then download more, than wait and finish up the request.

From the Wiki: 500 - The Server experienced an internal error and could not process the request.

James :-)

James, Urs enternacht, Paul and a few others were having a problem before THE outage, and the outage made their problems irrelevent. Now they are having it yet again, it seems, We've already been through most the diagnostic procedures (firewall, ports, ipconfig, dns flush, and many more) and haven't found a solution to their issues. I wish I could remember the thread name, but it's a very interesting problem.

tony

Also on dial up. I have had this problem for months. When there wasent much work to send the server 500 error went away for a few days.
Now it may take 30 or 40 tries before I get an UPDATE thru.
Nothing I have done has worked for long. It can take days to get an Update thru.
Been getting server 504 error also - makes a change.

Nairb

---

James, Urs enternacht, Paul and a few others were having a problem before THE outage, and the outage made their problems irrelevent. Now they are having it yet again, it seems, We've already been through most the diagnostic procedures (firewall, ports, ipconfig, dns flush, and many more) and haven't found a solution to their issues. I wish I could remember the thread name, but it's a very interesting problem.

tony

I remember the thread Tony, is he still usig a proxy to connect? (looking for that thread now)

James :-)

There was this thread where Galileo was being used as an option, not sure if it's still available as one now, I'm stil looking for the thread.


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

I think I found it: http://setiathome.berkeley.edu/forum_thread.php?id=18705

I hope that's it.

James :-)

There was this thread where Galileo was being used as an option, not sure if it's still available as one now, I'm stil looking for the thread.
http://setiathome.berkeley.edu/forum_thread.php?id=19428

Matt closed it at the time and I checked the other day and it is still closed.
galileo.ssl.berkeley.edu

---

Thanks for the feedback.....from Tonys other thread....

Ping is OK
Trace route appears to time out on one jump within the US then works OK (maybe there is a fault between Australia and the US).
Another computer using the same adsl link (but individually connected since I don't have a network set up) mostly connects OK.
My laptop at work never gets this failure (I have not done a traceroute at work and compared it to the one done at home - I might try that).
I have never lost a wu due to deadline issues so this is just painful.
Uploads work OK, it's just connecting to the scheduler for reporting of wu's and getting new work.
It is only a problem with seti@home not LHC, Predictor or Climate (I haven't done Einstein in a while).
I do not use a proxy normally, but do get it to connect via a proxy sometimes (until that one stops working and I have to find another - but I only do that once the wu's start getting a little old).
After 10 retries (I think) it does a master_file fetch gets it, but I still get the 500 failure.
Firewall all checked OK (even turned it off for a check - it is back on).
Anti-virus turned off as well for a check (it is back on).
Hmmm...wonder what else I've checked?
--------

I have 3 hosts, 2 PCs at home and a work laptop that is off for about a total of 1.5hrs per day as I commute between work and home. The laptop does not have a problem connecting at work - as said above I should do a traceroute from home and work and compare. I do not normally connect my laptop at home, but have done when I've run our of LHC work so I can't really compare. I will connect my laptop at home and do some seti uploads etc and compare.

The 2 PCs at home use a single non-networked usb adsl connection. My 3.2GHz HT machine is normally the always on connection and I see the 500 failure on auto retries and manual retries. My 2.0GHz box is mostly only connected to upload, report and download. It has recently had the problem, but not as much as the 3.2GHz machine, but then it's not always connected so it's hard to gauge. I have previously compared traceroutes and they show the same hops. I used Galileo with great success for a few hrs after the big outage but am now back to my normal non-proxy connection. I can usually connect using a proxy for a while, then I need to find another one.

I use BOINC V4.72 (all on XP) and am about to start using 5.1.x series (I'll let you know if I still have a problem after that). I think I was having the same problem with 4.45, but it has been a long time since I have used 4.45. If nothing else works I might wind back a few revs (4.45, 4.25 then 4.19) and see what happens.

Live long and crunch.

---

Paul
(S@H1 8888)
And proud of it!

I suppose this has already been mentioned.

Trying some of the tools at;

www.pcpitstop.com
or
www.dslreports.com/tools

Maybe some setting is off and one of their tools can help get it set right.

---

Thanks for the feedback.....from Tonys other thread....
Ping is OK
Trace route appears to time out on one jump within the US then works OK (maybe there is a fault between Australia and the US).

Just a thought then, try using the proxies in Europe and go the long way around.

---

I suppose this has already been mentioned.

Trying some of the tools at;

www.pcpitstop.com
or
www.dslreports.com/tools

Maybe some setting is off and one of their tools can help get it set right.

This problem is not likely to show in a traceroute or ping.

Paul's machine sends a TCP "SYN" packet. It arrives at Berkeley and he gets back a SYN+ACK. His machine then sends an ACK, possibly along with his request, and the servers in Berkeley get the request, and the request has an error. Paul's machine gets back the response with the 500. That packet gets an ACK.

This is a minimum of four successful packets. The BOINC protocol is a little verbose so it's probably more than four.

The $64,000 question is: why doesn't the request get through to Berkeley undamaged.

This is why someone else suggested "smaller packets" -- in case something between here and there is just dropping something when a packet is exactly a certain size (unlikely but possible) and why I suggested "no proxies" because a proxy will receive and resend the request, not simply forward it.

Paul also reported that he's on a slow DSL connection. Shorter packets should make it through better if his line is poor.

---

I suppose this has already been mentioned.

Trying some of the tools at;

www.pcpitstop.com
or
www.dslreports.com/tools

Maybe some setting is off and one of their tools can help get it set right.

This problem is not likely to show in a traceroute or ping.

Paul's machine sends a TCP "SYN" packet. It arrives at Berkeley and he gets back a SYN+ACK. His machine then sends an ACK, possibly along with his request, and the servers in Berkeley get the request, and the request has an error. Paul's machine gets back the response with the 500. That packet gets an ACK.

This is a minimum of four successful packets. The BOINC protocol is a little verbose so it's probably more than four.

The $64,000 question is: why doesn't the request get through to Berkeley undamaged.

This is why someone else suggested "smaller packets" -- in case something between here and there is just dropping something when a packet is exactly a certain size (unlikely but possible) and why I suggested "no proxies" because a proxy will receive and resend the request, not simply forward it.

Paul also reported that he's on a slow DSL connection. Shorter packets should make it through better if his line is poor.

Ned Hi,
You have seen a trace now of the packets? Any dropped packets?

Paul has not come back in the other thread to confirm a trace nor a reduced MTU. Have you heard from him?

---

Ned Hi,
You have seen a trace now of the packets? Any dropped packets?

Paul has not come back in the other thread to confirm a trace nor a reduced MTU. Have you heard from him?

I've not seen a traceroute and I haven't heard if he tried changing MTU from 1500 (the normal ethernet default) to something like 576 (the normal dialup default).

I'm pretty sure though that we aren't going to see much on the traceroute because he is connecting and he is getting a response. TCP is sufficiently robust that he shouldn't be having trouble if he can connect and get the "500" response, but there are 'broken' IP stacks out there.

I'd love to see what a smaller MTU does for him.

---

Ned Hi,
You have seen a trace now of the packets? Any dropped packets?

Paul has not come back in the other thread to confirm a trace nor a reduced MTU. Have you heard from him?

I've not seen a traceroute and I haven't heard if he tried changing MTU from 1500 (the normal ethernet default) to something like 576 (the normal dialup default).

I'm pretty sure though that we aren't going to see much on the traceroute because he is connecting and he is getting a response. TCP is sufficiently robust that he shouldn't be having trouble if he can connect and get the "500" response, but there are 'broken' IP stacks out there.

I'd love to see what a smaller MTU does for him.

OK. I was hoping for an ethereal trace to see what was sent and how the server was responding. I guess we wait for him to try that and to reduce his MTU size. Interesting one. I don't know of you can recall but is this the one where there is satellite involved?

---

OK. I was hoping for an ethereal trace to see what was sent and how the server was responding. I guess we wait for him to try that and to reduce his MTU size. Interesting one. I don't know of you can recall but is this the one where there is satellite involved?

What I'd like to see is some sort of Ethereal trace or something like that from near the server. If it's close to Paul we'd know it's getting out of his machine okay, but have no idea how it gets molested by the time it reaches the scheduler.

Changing MTU may not help, but if it does, we're golden. If it doesn't, well, it isn't that hard to change it back.

I included a link to DrTCP on another message as that is an easy way to fiddle.

---

Ned Hi,
You have seen a trace now of the packets? Any dropped packets?

Paul has not come back in the other thread to confirm a trace nor a reduced MTU. Have you heard from him?

I've not seen a traceroute and I haven't heard if he tried changing MTU from 1500 (the normal ethernet default) to something like 576 (the normal dialup default).

I'm pretty sure though that we aren't going to see much on the traceroute because he is connecting and he is getting a response. TCP is sufficiently robust that he shouldn't be having trouble if he can connect and get the "500" response, but there are 'broken' IP stacks out there.

I'd love to see what a smaller MTU does for him.

Sorry for the long delay between responses, it's been extrememly busy at work and home. And thanks for the repsonses. It really is appreciated.

I haven't dropped the MTU down to 500 or 576 yet. It is currently at 1492. The slow ADSL connection is just what I'm paying for. "Broadband" downunder is extremely expensive. What I pay $A49.90 per month for you'd get a 1.5Mbit to 5Mbit connection, but I get a 256kbit connection with unlimited downloads. My closeness to the telephone exchange means if I wanted an ADSL2 connection I could get one, but it ain't worth the money (and the Australian government wonders why the uptake of broadband is slow - but that's what happens with a pseudo monopoly - but I digress). As I have said previously I do not have a problem with other projects (LHC, CPDN, Predictor).

I'm currently hammering away on LHC trying to resist being overtaken for total credit by a teammate for as long as possible (his ARC is 1100, mine is 460 so it is just a matter of hrs now). Once I am overtaken I will be setting the resource share back to where it was and seti will get a few cycles on this machine and we will be able to see if things improve with a lower MTU, but I still don't understand why that would make a difference when I can connect and do other projects with no problems what-so-ever.

Live long and crunch.

---

Paul
(S@H1 8888)
And proud of it!