This was the 4th time the project was down in less than a week for multiple consecutive hours without any explanation.

And now it's back online with all the projects I have worked on in last day reporting negative hours.

Did the project have another database problem or something else break?

---

My hours are not increasing but no negatives this time.
Edit: Now incrementing.

Better to return to 6 hour work units to reduce server load.

Paul.

Seem to have been down for about 7 hours and this time I have negative hours. I agree, better return to the 6 hours WUs (or even better: let us choose like Rosetta), that will not only reduce the server load, we will also get better chance to make it thru the outage without loosing any hours.

---

.

Seem to have been down for about 7 hours and this time I have negative hours. I agree, better return to the 6 hours WUs (or even better: let us choose like Rosetta), that will not only reduce the server load, we will also get better chance to make it thru the outage without loosing any hours.

I like this idea as it might make it alot better for Android devices with the smaller tasks while desktops, Servers and laptop can easily handle the 6 hour tasks with a lot less bandwidth and wear and tear on the wuprop hardware.

BUT what I'd like to really know is if there is anything we users can do to help alleviate any future unplanned outages ie help with newer and bigger hard drives, more memory for the Server or pc(s) it runs on, more bandwidth etc etc.

Another 6 to 8 hour outage today. The multi-hour outages appear to come in waves aprox Two days apart in a week.
Loosing many hours on apps due to the extended outages.
Agree Time to go back to a 6 hour task across the board.

*** EDIT TO ADD >>> AND THE NEGATIVE HOURS ARE BACK ALSO <<< ***

---

Another 6 to 8 hour outage today. The multi-hour outages appear to come in waves aprox Two days apart in a week.
Loosing many hours on apps due to the extended outages.
Agree Time to go back to a 6 hour task across the board.

*** EDIT TO ADD >>> AND THE NEGATIVE HOURS ARE BACK ALSO <<< ***

Another thought I had was to treat the tasks like other Boinc Projects and just send out several at a time, that way if the Server is down we just move to the next task, and then the task after that etc. Boinc uses a first in first out basis for it's tasks, which can then be affected by return times, but instead of banging the Server we would just hold the completed tasks and not lose any time until the Server is ready to take them all back again.

Boinc uses a first in first out basis for it's tasks, which can then be affected by return times, but instead of banging the Server we would just hold the completed tasks and not lose any time until the Server is ready to take them all back again.

Won't it run them all at once, since they are NCI? Goofyxgrid has also send just one task per app and they were all running concurrently.

---

.

Boinc uses a first in first out basis for it's tasks, which can then be affected by return times, but instead of banging the Server we would just hold the completed tasks and not lose any time until the Server is ready to take them all back again.

Won't it run them all at once, since they are NCI? Goofyxgrid has also send just one task per app and they were all running concurrently.

More than likely. I don't think BOINC NCI works that way - all or nothing run.

Every NCI project I have attached & completed work on has only sent one task per computer except the old GoofyGrid would send multiples at times and occasionally I get multiple tasks running at once on iThena's main NCI project.

And we're back from another multi hour outage along with negative hours for the third day now.....

I am happy that we have this project even if it is occasionally intermittent. Complaining each and every time that the server hiccups doesn't do anyone any good. Sebastien needs sleep just like the rest of us, cut him some slack.

---

I am happy that we have this project even if it is occasionally intermittent. Complaining each and every time that the server hiccups doesn't do anyone any good. Sebastien needs sleep just like the rest of us, cut him some slack.

I don't think it's the complaining so much as that there's been no explanation of why and if anyone of us can help solve the problem. I know Sebastien got some helpers awhile back when the Project was on the verge of collapsing, does he need more? Does he need some hardware that keeps failing? Is it a software problem? Is it an ISP problem? In short people are trying to figure out if they can help but with no word coming from 'the Team, it's kinda hard.

Complaining each and every time that the server hiccups doesn't do anyone any good.

We are not complaining, at least I'm not, just reporting an issue, which he might even not notice otherwise if it's always fixing itself after couple of hours. I don't see anything wrong with reporting bugs or other issues to the admin/developer, that's how admins/devs get to know there's something wrong at all with their servers/software/whatever in most cases, they might not notice the issue from their end without the reports.

---

.

Getting a couple of projects reporting negative hours myself.

---

Getting a couple of projects reporting negative hours myself.

I just got a huge update on some of my projects!!

Same, Mikey

---

Same here.
It appears the "extra" hours are counting about 2.5 to 3 calendar days of back reporting of work based on my last 24 hours per device page.

Now it is "Server error: feeder not running"

EDIT: and back online again

Agree Time to go back to a 6 hour task across the board.

If server load because of too many clients connecting the scheduler is the issue, than perhaps increasing <next_rpc_delay> might help a bit at least, currently I see this stupid behavior for each WU:

29/04/2023 12:38:19 | WUProp@Home | Sending scheduler request: Requested by project.
29/04/2023 12:38:19 | WUProp@Home | Not requesting tasks: non CPU intensive
29/04/2023 12:38:20 | WUProp@Home | Scheduler request completed
29/04/2023 12:38:31 | WUProp@Home | Computation for task data_collect_v4_1682702101_52217_0 finished
29/04/2023 12:38:33 | WUProp@Home | Started upload of data_collect_v4_1682702101_52217_0_0
29/04/2023 12:38:35 | WUProp@Home | Finished upload of data_collect_v4_1682702101_52217_0_0
29/04/2023 12:38:35 | WUProp@Home | Sending scheduler request: To report completed tasks.
29/04/2023 12:38:35 | WUProp@Home | Reporting 1 completed tasks
29/04/2023 12:38:35 | WUProp@Home | Requesting new tasks for CPU
29/04/2023 12:38:36 | WUProp@Home | Scheduler request completed: got 1 new tasks
29/04/2023 12:38:38 | WUProp@Home | Started download of data_collect_v4_1682702101_43298
29/04/2023 12:38:39 | WUProp@Home | Finished download of data_collect_v4_1682702101_43298
29/04/2023 12:38:39 | WUProp@Home | Starting task data_collect_v4_1682702101_43298_1

The first request is completely unnecessary and without <report_results_immediately/> in app_config.xml it slows down getting a new WU by few seconds. To avoid this while still keeping the function of forced scheduler requests <next_rpc_delay> should be increased from the current 3600 to 3700 seconds.

---

.

I see we had Two "short" outages in about 48 hours..
WuProp database is back up along with the usual NEGATIVE HOURS

I'm just glad the project is still with us.

Is there a Patreon donation link?