Joined: 5 Aug 02
That is exactly my point!! I went from 75K+RAC/day to ZERO. "Project has no tasks available." This does not keep my 5 systems happy at all. Now it is Friday; all personel have left for the weekend; and SETI is sitting idle (it seems).
The issue with the 6.12.xx BOINC versions is the long back-off times compared to 6.10.58 or .60. Many of the larger/faster rigs that have stepped back to 6.10.60 are experiencing significantly less problems with workfetch since they "downgraded". There are several threads in Number Crunching that address that issue.
Infernal Optimist / Submariner, retired
Joined: 11 Nov 99
The problem with E@H seems to mainly involve two things they are doing.
First is the way E@H sets their deadlines. They attach -extremely- short deadlines on all their tasks. This causes BOINC to place their tasks' execution priority far ahead of all the other applications' tasks so that the E@H tasks don't expire. This is great for E@H, but gives what one might almost call an "unfair" advantage to their project. This is great for E@H, but makes it difficult for the other projects to either get equal run time or to get the resource distribution you desire.
Second is the rather large number of tasks E@H sends you every time BOINC requests new tasks. The sudden addition of so many longer-running tasks overloads the system and, combined with the short deadlines, gives their tasks priority over the other applications.
I have found that adjusting the Einstein resource allocations to a lower number for E@H helps, but it's -very- difficult to get the right mix of allocations to get E@H to request new tasks on a low allocation versus grabbing too much execution time on slightly higher allocations. I have for some time been experimenting with various ways to get the project mix back to what I prefer on my machines, but E@H's rather unusual combination of deadlines and download limits still interferes with both BOINC's processing distribution and new task request programming. Despite my best efforts, I have to periodically manually intervene to get the mix back to what I want.
The easiest manual intervention method I have found is the following:
1. Select the "Projects" tab.
2. Select (highlight) all projects.
3. Select "No new tasks".
4. Select (highlight) all projects I do not want to change.
5. Select "Suspend".
6. Select (highlight) the project that is now short on new tasks.
7. Select "Allow new tasks"
8. If the low-task project doesn't immediately request new tasks, select "Update".
Watch the project closely so you don't get too many tasks at once. As soon as enough tasks to get things back on track begin to download, reverse the process via the "Projects" tab as follows:
1. Select (highlight) the project that is downloading the new tasks.
2. Select "No new tasks"
3. Select (highlight) all suspended projects.
4. Select "Resume"
5. Select (highlight) all projects.
6. Select "Allow new tasks".
This is a rough way to get around it, but so far it's the only work-around I've found.
Perhaps the only true solution is for BOINC to issue some new "guidelines" to the various Project Administrators on deadlines and quotas and then modify BOINC's programming to handle any accidental variance from these guidelines.
As to your question about the "high priority" status on a running task, it appears to be related more to the deadline date. It seems that a task is placed in "high priority" status if the remaining time versus the deadline place it in jeopardy of not completing in time. I have not found evidence that this has anything to do with physical load on the GPU, but I may be wrong. Perhaps someone else knows the answer to this.
Finally, Cliff, the "dumped" task problem is again related to deadlines. If one or more tasks either have not yet started, or get dangerously close to not completing by their deadlines based on remaining processing time, BOINC will stop running one or more tasks that are not so time-critical and begin running the "at risk" tasks. Don't worry, as long as there are not too many tasks on your machine to complete in time, BOINC will resume computation on the "dumped" task as soon as the "at risk" tasks complete.
I hope this helps, Cliff, and I invite additional insight from anyone who may have found an easier way to deal with this problem. Just like Cliff and the rest of us experiencing this problem, I sure would like any help on how to get BOINC back to running smoothly without so much manual intervention.
©2017 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.