I have observed that PrimeGrid and Boincsimap will send units with a very quick report deadline so that they will be run as High Priority projects. The High Priority designation will allow the project to monopolize my computer resources by not switching to other projects as set in my configuration files. I have also noticed that Einstein@home has extremely large time requirements. This has a tendency to block other projects from downloading work units to run, so it takes a high priority status by being the only project on the system. There should be some way to control maximum work unit time size and work unit priority.

There should be some way to control maximum work unit time size and work unit priority.

Or just don't download so much work per project. Then your computer would have time to switch as normal between projects/tasks and get everything done before a possible deadline. The projects set the deadline on the tasks. They decide when the work needs to be returned, not us.

But if you want to fiddle with the settings, Rosetta has the option for you to set how long you want to run any given task.

---

I have the same problem, with a different mix off projects.

However, I have on project not due until 20 Oct running priority over a project due tomorrow, I may have to suspend project just to get it to run the next due.

I'd be happy if you could just turn off priority so that switching happens as I set it (ie every hour).

I have also noticed that Einstein@home has extremely large time requirements. This has a tendency to block other projects from downloading work units to run, so it takes a high priority status by being the only project on the system. There should be some way to control maximum work unit time size and work unit priority.

QMC is even worse! On the machine I run it on (a 2.53 ghz Celeron), it comes up with estimates of up to 120 hrs, as against up to about 60 for Einstein, but the deadlines for QMC units don't vary with estimated crunching time. QMC then actually takes less than half of the estimated time, which, together with the tight deadlines, rather cleverly ensures that each work unit runs high priority from day 1, and means that the machine has to crunch for at least 3 hours per day before it is allowed to switch to any other project.

However, any project with long crunching times will have built up a large negative long term debt by the time the work unit is finished, meaning that your machine will crunch for other projects in between large indigestible chunks of work. The only problem may be if QMC or Einstein gives you a large work unit while you still have short work units in progress for other projects. What I do then is keep my machine switched on for long enough each day to do the required number of hours per day of crunching. Serves me right for running so many projects on one machine I guess...

---

I have found that suspending *some* of the tasks that have a
status of "ready to start" for a project running high priority
will cause the active tasks to exit high priority status and
allows normal switching to resume.