At this time I am unable to get work from the website an they appears to be plenty in the que. I've tried resetting, detaching and reattaching.

Jerry

---

Are the workunit generator programs running slower than usual? I just noticed the system status shows both running, but only 63 workunits ready to send.

Hi Mod, sorry for the previous claim regarding one of two computers - I had a bad day obviously and haven't seen the 0 seconds of work requested. Despite of that, the claim regarding my 2nd computer was valid.

For many hours there were no problems, however presently once again we seem to be dry of WUs:

2009-01-18 15:42:16|rosetta@home|Sending scheduler request: Requested by user. Requesting 2495 seconds of work, reporting 1 completed tasks
2009-01-18 15:42:21|rosetta@home|Scheduler request succeeded: got 0 new tasks

Best Regards for all.
a.m.

Today, I noticed a problem I hadn't seen before. On your Server Status web page, the programs in Disabled status are shown with the same green block as for the normal status, making any status changes hard to spot. Could you change this to using blocks of a different color, for example red, for the Disabled status?

Of course, ending the Disabled status faster would be welcome too.

Right --- a bit misleading that. As is the home page announcement which implies that things are up and running -- clearly there is a bit more 'work to do' before that is the case.

Today, I noticed a problem I hadn't seen before. On your Server Status web page, the programs in Disabled status are shown with the same green block as for the normal status, making any status changes hard to spot. Could you change this to using blocks of a different color, for example red, for the Disabled status?

Of course, ending the Disabled status faster would be welcome too.

---

you can upload files but there is no work at the moment for download.
"project maintenance" is what the message says.

Right --- a bit misleading that. As is the home page announcement which implies that things are up and running -- clearly there is a bit more 'work to do' before that is the case.

Today, I noticed a problem I hadn't seen before. On your Server Status web page, the programs in Disabled status are shown with the same green block as for the normal status, making any status changes hard to spot. Could you change this to using blocks of a different color, for example red, for the Disabled status?

Of course, ending the Disabled status faster would be welcome too.

A slight clarification -- you can upload files, but you can't *report* them. Those green status lights indicating disabled (they really should be red or orange like other BOINC projects when disabled or not running) mean that you can't report completed work.

The message on the home page which is a bit misleading is this:

February 16, 2009
A fileserver/SAN hiccup caused the entire project to pause for a number of hours. Sorry for the outage. -KEL

**********

Not a big deal, but if it had said something like this:

A fileserver/SAN hiccup caused the entire project to pause for a number of hours. We are working toward correcting the problem. A number of the critical functions are still offline but we hope to have them corrected as soon as possible. Sorry for the ongoing outage. -KEL
********************************************

Then folks would have a more accurate idea of what is going on. Again, not that big a deal, I've got plenty of other projects that are reasonably happy at the moment.

you can upload files but there is no work at the moment for download.
"project maintenance" is what the message says.

---

Update -- looks like the servers are now back online, but struggling with a lot of 'catch up' traffic so things will likely be slow going for a while.

---

I was able as of that last post to upload and report. But no new work is being sent due to what the manager says is a lack of headers and data.

server status says everything is running but no results can be uploaded. ???

huh??

---

Just when I put my 8 CPU system onto the project ... :)

Not sure why this message:

{error}Proposed work request 596265.165152 bigger than max 174534.981120

With 8 cores and 3 hours per task I am sure I can plow through quite a bit in 24 hours and a cache of 0.5 days is also not unreasonable.

Anyway ... another item to consider ...

Fortunately, I'm now able to upload and report. Unfortunately, I can't get any new WUs. My messages just say there's no work from project; there's no mention of headers or anything like that. But the RAH home page and server page say that everything is running fine and there are some 10k WUs ready to send. I even changed my prefs to have the WUs last 4 hours instead of my usual 6, and that didn't get me anything. I can't believe all 10,000 WUs are for running times other than 4 or 6 hours. Am I doing anything wrong now?

---

Fortunately, I'm now able to upload and report. Unfortunately, I can't get any new WUs. My messages just say there's no work from project; there's no mention of headers or anything like that. But the RAH home page and server page say that everything is running fine and there are some 10k WUs ready to send. I even changed my prefs to have the WUs last 4 hours instead of my usual 6, and that didn't get me anything. I can't believe all 10,000 WUs are for running times other than 4 or 6 hours. Am I doing anything wrong now?

No ...

One of the "problems" with the systems we use is that the information is accurate as far as it goes, but does not always convey the entire story. I was in the same boat as you but now seem to have gotten work ... as the front page says ... major hiccup ...

{edit}

Oops, now we are queue =0 ... out of work to send ... my bad ...

The issue will be now that there is likely no one there to kick the work generator to make more work to feed the hungry beasts ...

My issue is now fixed. I even got WUs before they ran dry! :p

---

My issue is now fixed. I even got WUs before they ran dry! :p

The work generator is running ... but it is having a hard time getting ahead of the curve. Probably all my fault ... :)

Actually, it is pretty common after an outage that the work generator has a hard time because the participants need to re-fill their work queues.

I'm currently unable to connect with the web site over on Ralph@home, or connect to its servers. Is there a problem over there?

I'm currently unable to connect with the web site over on Ralph@home, or connect to its servers. Is there a problem over there?

Ditto!

I have a cache of work - approx 150 WU waiting to report. Deadline is today.

---

SETI.USA

I'm currently unable to connect with the web site over on Ralph@home, or connect to its servers. Is there a problem over there?

RALPH@home is now running again. No word yet on what caused the outage, only that there was one.

I'm currently unable to connect with the web site over on Ralph@home, or connect to its servers. Is there a problem over there?

RALPH@home is now running again. No word yet on what caused the outage, only that there was one.

I had a drought of tasks and now I have a pretty tall stack. The good news such as it is, is that I don't seem to be seeing any errors with 1.58 and that is pretty good ...

I'm currently unable to connect with the web site over on Ralph@home, or connect to its servers. Is there a problem over there?

RALPH@home is now running again. No word yet on what caused the outage, only that there was one.

I had a drought of tasks and now I have a pretty tall stack. The good news such as it is, is that I don't seem to be seeing any errors with 1.58 and that is pretty good ...

I've seen some errors with 1.58, but it seems to require an unusual (at least for RALPH@home participants) combination of events to cause them:

1. CPU usage set less than 100%.
2. At least some graphics use for displaying that workunit's progress.
3. Possibly, also shutting off the graphics display for that workunit.

However, once started, the problem tends to last for more than one workunit.

Also there's a second error type that seems to depend on details of the workunit, but RALPH@home was intended partly to find such errors before that type of workunit reaches Rosetta@home.