LOL, I'm sympathizing. I learned a few years back that BOINC simply doesn't have enough fine-grained tools to handle projects like Einstein. I have tried all tricks mentioned. Nothing worked. My simple solution is NNT on Einstein until I'm low on work. Then allow tasks for two download cycles, which takes all of two minutes, and shut her off again. That gets me around 2-3 days of work before I have to run the process again. Oh well..... everyone that has an abundance of Einstein work is going to see a huge bump in their overall BOINC RAC.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

. . Did you set the E@H resource priority to 0%? That advice proved successful for me.

I also added E@H, but couldn't find where to set resource proiority....?

I too wasn't able to find the setting in BOINC Manager to change the priority on projects. And I made the mistake of downloading a crap load of tasks from 2 other projects so it might be a couple days before my Windows machine is able to start the Seti tasks it has. But I'm glad to wake up and see new Seti tasks have been downloaded to my 2 best computers!

To set resource priority to other than the default 100, on the E@H web page, under tabs:
Account>Preferences>Project
it's the first field, Resource Share.

Like others, it may be a while before I'm back to pumping SETI, as I ended up with like 5600 tasks between 5 machines before I could get it choked off.

. . And I thought I had screwed up by getting about 90 on one machine and 30 to 50 on another. 5600 is a hell of lot of tasks ....

Stephen

?

LOL, I'm sympathizing. I learned a few years back that BOINC simply doesn't have enough fine-grained tools to handle projects like Einstein. I have tried all tricks mentioned. Nothing worked. My simple solution is NNT on Einstein until I'm low on work. Then allow tasks for two download cycles, which takes all of two minutes, and shut her off again. That gets me around 2-3 days of work before I have to run the process again. Oh well..... everyone that has an abundance of Einstein work is going to see a huge bump in their overall BOINC RAC.

With mine set to 0, I only get enough to keep the GPUs busy and 1 more. They will continue to crunch Einstein until I get Seti work, then they finish the Einstein and start up on the Seti work...

---

. . And I thought I had screwed up by getting about 90 on one machine and 30 to 50 on another. 5600 is a hell of lot of tasks ....

Stephen

?

That is for me is a really common onboard task count for Einstein. That is about 2-3 days work at my 12.5% resource share with SETI.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

With mine set to 0, I only get enough to keep the GPUs busy and 1 more. They will continue to crunch Einstein until I get Seti work, then they finish the Einstein and start up on the Seti work...

But I don't use Einstein just as a backup project. I actively crunch at 12.5% usage and 7.5% usage for MilkyWay.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

. . And I thought I had screwed up by getting about 90 on one machine and 30 to 50 on another. 5600 is a hell of lot of tasks ....
Stephen
?

Yeah, I screwed the pooch so bad on that one they heard it blocks down the road!:)
And somehow I managed that with tasks set to 1+1 days, and priority at 1.
Could be wrong, but I think the deal is that initial hit to the web site gets you downloads before the preferences are read and accepted.
So it goes ...
Simple lesson I know well and always ignore is to make changes on just one box, then wait a day or two to see and deal with any fallout.
But, being a charge-ahead kinda guy, ....

---

I also got a heap of E@H WUs before I had the sense to set NNT. Saving them for Tuesday now. Setting resource share to 0 seems to work well enough, the active tasks just sit there 'Waining to run'.

---

Humans may rule the world...but bacteria run it...

LOL, I'm sympathizing. I learned a few years back that BOINC simply doesn't have enough fine-grained tools to handle projects like Einstein. I have tried all tricks mentioned. Nothing worked. My simple solution is NNT on Einstein until I'm low on work. Then allow tasks for two download cycles, which takes all of two minutes, and shut her off again. That gets me around 2-3 days of work before I have to run the process again. Oh well..... everyone that has an abundance of Einstein work is going to see a huge bump in their overall BOINC RAC.

With mine set to 0, I only get enough to keep the GPUs busy and 1 more. They will continue to crunch Einstein until I get Seti work, then they finish the Einstein and start up on the Seti work...

. . Yep, it works pretty much the same for me. When one E@H task finishes I get another to run. Just enough to keep the mill grinding, and no more. So when Seti work does start to flow there is only one E@H tasks to finish on each GPU. And that doesn't take that long either.

Stephen

:)

. . And I thought I had screwed up by getting about 90 on one machine and 30 to 50 on another. 5600 is a hell of lot of tasks ....
Stephen
?

Yeah, I screwed the pooch so bad on that one they heard it blocks down the road!:)
And somehow I managed that with tasks set to 1+1 days, and priority at 1.
Could be wrong, but I think the deal is that initial hit to the web site gets you downloads before the preferences are read and accepted.
So it goes ...
Simple lesson I know well and always ignore is to make changes on just one box, then wait a day or two to see and deal with any fallout.
But, being a charge-ahead kinda guy, ....

. . Damn the torpedoes, full speed a...... OOPS!

Stephen

:)

But, being a charge-ahead kinda guy, ....

. . Damn the torpedoes, full speed a...... OOPS!

Stephen

:)

Yep. I think I code that way too ! :)

---

Seems there are a few WUs apparently Hung. I was looking for a particular AR and found one in Suspended Animation. Then I found a few more just sitting there waiting for the Validator. They have been waiting a couple of days, some a few weeks. Anyway to resurrect these dead WUs and get them moving again?
http://setiathome.berkeley.edu/workunit.php?wuid=2377405378
http://setiathome.berkeley.edu/workunit.php?wuid=2485675271
http://setiathome.berkeley.edu/workunit.php?wuid=2485884961
http://setiathome.berkeley.edu/workunit.php?wuid=2485926712

It looks as though most of these WUs were started before the Outage, and the competed tasks since the Outage are not being acknowledged by the Validator as needing Validation.

I've had similar occur in the past. Nothing we can do on our end as far as I know. You just have to wait for the assimilators to process them or wait for Eric to run a script to clear out the deadwood.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Yes, and now you have a few more "Dead" tasks, https://setiathome.berkeley.edu/results.php?hostid=8030022&offset=420&state=2
In fact, I'd say it's safe to assume Anyone that had Pending Tasks at the start of the Outage has 'Dead' tasks.
Hundreds of thousands...or more ;-)
I have quite a few across Four machines. As the scenario suggests, probably Everyone does.

Yuck. So maybe there are still some crossed wires in the servers because of the data corruption remedy.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Looks like the SETI WU and results awaiting purge flatlined right around 00:00 UTC Monday. Haveland Stats

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Yes, and now you have a few more "Dead" tasks, https://setiathome.berkeley.edu/results.php?hostid=8030022&offset=420&state=2
In fact, I'd say it's safe to assume Anyone that had Pending Tasks at the start of the Outage has 'Dead' tasks.
Hundreds of thousands...or more ;-)
I have quite a few across Four machines. As the scenario suggests, probably Everyone does.

. . Ouch, that would explain the big drop in my acknowledged returns since the unscheduled outage :(

. . Oh well..

Stephen

<shrug>

Web site and forums behaving badly at the moment.
Slow to respond, and other times not even responding at all.

EDIT- just had a look in my Manager's Event log & a few Scheduler errors (Couldn't connect to server) are showing there.

---

Grant
Darwin NT

Yes, I've been seeing the same slowness and no server response too.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Yes, I've been seeing the same slowness and no server response too.

. . That was probably me writing a long message .. :) <joke>

Stephen

:)

Web site and forums behaving badly at the moment.
Slow to respond, and other times not even responding at all.

EDIT- just had a look in my Manager's Event log & a few Scheduler errors (Couldn't connect to server) are showing there.

In scanning my stdoutdae.txt I do see a slight increase in the number of scheduler failures over the course of this past week.

Project details for: SETI@home including all dates
Scheduler Requests: 4090
Scheduler Success: 99 %, Count: 4062
Scheduler Failure: 0 %, Count: 28 (Total)
Scheduler Failure: 0 % of total, Count: 24 (Couldn't connect to server)
Scheduler Failure: 0 % of total, Count: 3 (HTTP service unavailable)
Scheduler Failure: 0 % of total, Count: 0 (HTTP internal server error)
Scheduler Failure: 0 % of total, Count: 1 (Failure when receiving data from the peer)
Scheduler Failure: 0 % of total, Count: 0 (Timeout was reached)
Scheduler Timeout: 0 % of failures

Project details for: SETI@home including 08-Apr-2017
Scheduler Requests: 217
Scheduler Success: 98 %, Count: 214
Scheduler Failure: 1 %, Count: 3 (Total)
Scheduler Failure: 1 % of total, Count: 3 (Couldn't connect to server)

Project details for: SETI@home including 07-Apr-2017
Scheduler Requests: 480
Scheduler Success: 99 %, Count: 479
Scheduler Failure: 0 %, Count: 1 (Total)
Scheduler Failure: 0 % of total, Count: 1 (Couldn't connect to server)

Project details for: SETI@home including 06-Apr-2017
Scheduler Requests: 479
Scheduler Success: 99 %, Count: 476
Scheduler Failure: 0 %, Count: 3 (Total)
Scheduler Failure: 0 % of total, Count: 2 (Couldn't connect to server)
Scheduler Failure: 0 % of total, Count: 1 (HTTP service unavailable)

Project details for: SETI@home including 05-Apr-2017
Scheduler Requests: 478
Scheduler Success: 99 %, Count: 474
Scheduler Failure: 0 %, Count: 4 (Total)
Scheduler Failure: 0 % of total, Count: 2 (Couldn't connect to server)
Scheduler Failure: 0 % of total, Count: 2 (HTTP service unavailable)

Project details for: SETI@home including 04-Apr-2017
Scheduler Requests: 381
Scheduler Success: 99 %, Count: 379
Scheduler Failure: 0 %, Count: 2 (Total)
Scheduler Failure: 0 % of total, Count: 2 (Couldn't connect to server)

Project details for: SETI@home including 03-Apr-2017
Scheduler Requests: 480
Scheduler Success: 99 %, Count: 476
Scheduler Failure: 0 %, Count: 4 (Total)
Scheduler Failure: 0 % of total, Count: 4 (Couldn't connect to server)

Project details for: SETI@home including 02-Apr-2017
Scheduler Requests: 480
Scheduler Success: 100 %, Count: 480
Scheduler Failure: 0 %, Count: 0 (Total)

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[