I noticed that none of my computers were uploading or downloading. It looks like kryten bit the dust. Hopefully it is just a hiccup.

http://setiathome.berkeley.edu/sah_status.html

>Fred

---

http://www.teamstarfire.org/

kryten didn't bite the dust...
its the amount of work it has to do temperarily...

BoB

---

Do you Good Search for Seti@Home? http://www.goodsearch.com/?charityid=888957
Or Good Shop? http://www.goodshop.com/?charityid=888957

kryten didn't bite the dust...
its the amount of work it has to do temperarily...

BoB

Are there really a problem with the scheduler in the moment ? - In the help desk forums has some users problems with attaching/download and upload reported.

---

Are there really a problem with the scheduler in the moment ? - In the help desk forums has some users problems with attaching/download and upload reported.

Yes, it seems there is a problem

30/12/2005 16:23:02||Network error: couldn't connect to server
30/12/2005 16:23:05|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed: http error
30/12/2005 16:23:05|SETI@home|No schedulers responded

See also Seti/Boinc project status.

Edit
Problem seems to be resolved right now.

Are there really a problem with the scheduler in the moment ? - In the help desk forums has some users problems with attaching/download and upload reported.

Yes, it seems there is a problem

30/12/2005 16:23:02||Network error: couldn't connect to server
30/12/2005 16:23:05|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed: http error
30/12/2005 16:23:05|SETI@home|No schedulers responded

See also Seti/Boinc project status.

Edit
Problem seems to be resolved right now.

I'm still getting error messages:
12/30/2005 8:31:42 AM|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
12/30/2005 8:31:42 AM|SETI@home|Reason: To fetch work
12/30/2005 8:31:42 AM|SETI@home|Requesting 29479 seconds of new work
12/30/2005 8:32:07 AM||Couldn't connect to hostname [setiboinc.ssl.berkeley.edu]
12/30/2005 8:32:11 AM|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -106
12/30/2005 8:32:11 AM|SETI@home|No schedulers responded


Since then my other projects have downloaded work, so SETI won't download more now. :-)

---

Are there really a problem with the scheduler in the moment ? - {snip}]

Not that I can see, I just emptied my last 24 hours worth of done WU's and they went through no problems, and ditto, the arrival of replacement WU's for the next 24 hours.

None of then have been validated yet, even though there is a quorum on many, but that's another issue....

---

Foamy is "Lord and Master".
(Oh, + some Classic WUs too.)

I'm still getting error messages:
12/30/2005 8:31:42 AM|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
12/30/2005 8:31:42 AM|SETI@home|Reason: To fetch work
12/30/2005 8:31:42 AM|SETI@home|Requesting 29479 seconds of new work
12/30/2005 8:32:07 AM||Couldn't connect to hostname [setiboinc.ssl.berkeley.edu]
12/30/2005 8:32:11 AM|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed with a return value of -106
12/30/2005 8:32:11 AM|SETI@home|No schedulers responded


Since then my other projects have downloaded work, so SETI won't download more now. :-)

-106 is "failed to open file"

In this case, the "file" is actually a TCP connection to setiboinc.ssl.berkeley.edu.

There are many reasons that this might happen, which can range from "not dialed in" to a routing problem between you and UC Berkeley, to a problem inside the Berkeley (CNS) network, to someone on the SETI staff working on that machine.

Usually, these problems fix themselves in a few hours, and if you are running a big cache and lots of projects, BOINC will do more SETI later to make up for it.

---

Wow, these outages are more common than one would think. With todays faster CPU's the workunits don't arrive fast enough to satisfy them. Hmm, a new years resolution, a better queuing system should be devised.

Fustrating to say the least.

---

Wow, these outages are more common than one would think. With todays faster CPU's the workunits don't arrive fast enough to satisfy them. Hmm, a new years resolution, a better queuing system should be devised.

Fustrating to say the least.

Its not a problem at all.

1. Increase your cache size. http://setiathome.berkeley.edu/prefs.php?subset=global.

Network usage
Connect to network about every

Set this value higher. The default is 0.1 days. I run mine at 0.9 days, but many run it much higher (though the maximum is 10 days, this is really not a good idea if you run more than one project). A safe value (assuming S@H only) would be 5 to 7 days. More than one project: try 10 / (# of projects).

2. If you are using dial-up, get some form of broadband access if at all possible. The 'always on' connection makes it MUCH easier to get and return work as needed.

3. Participate in more than one BOINC project. This way your computer can do work on the other project(s) when (not IF, but WHEN) S@H is down or out of work. No DC project can guarantee either 100% uptime or 100% work availability. BOINC was designed to be fault-tolerant of this. The BOINC client will 'give back' the extra time spent processing the other project(s) to S@H when S@H comes back up (per your resource shares).

4. Yes, S@H/BOINC has frequent outages. A lot of the current problems are due to various tasks the staff have to do after S@H-Classic shut down. Classic had frequent problems & outages as well (especially in 1999 and 2000). Its just that most of them were not visible to the community of participants. BOINC kinda makes that sort of dirty laundry visible to the community at large. We tend to know every time a server at Berkeley sneezes. Don't sweat it. Everything is working. Yes, there are some clogs in the plumbing, but the project staff are busy with their 'roto-rooters' fixing them.

Have a nice day, and a happy new year.

---

https://youtu.be/iY57ErBkFFE

#Texit

Don't blame me, I voted for Johnson(L) in 2016.

Truth is dangerous... especially when it challenges those in power.