Hey hey,

I would like to ask for a new option in BOINC. The possibility to switch off the high priority function.

Over the last two years I have lost account-less hours of calculation time due to the high priority function. Can't name them all but think about many hour ECM work units from yoyo@home that doesn't do saves and then BOINC fires up some other work units. :|

I rather be able to manage it myself than having BOINC ruining it.

Best Regards,

iconized, DPC.

I am well aware of those tricks and possibilities, but the high priority function in BOINC is just borged. So I want to be able to switch it off.

If you have a lot of work going into high priority, either your cache is too big, your computer isn't on enough to run what work is in cache, or you don't allow BOINC to run long enough to run that work in cache.

I have work from 8 different projects in cache (Einstein, Albert, LHC 1.0, Correlizer, Seti, Enigma, Leiden and Rosetta), on a connect to of 0.1 and an additional of 1.00, while this BOINC is only allowed to run between 9pm and 7am when electricity is at its cheapest and then use only 2 or 3 of the cores, instead of all 4 as I don't want to take the case apart at this time to clean the dust bunnies out again.

Off late the amount of time BOINC has been on has even been less, since I also play a lot of Skyrim (Elder Scrolls V), which I can tell you isn't something you finish playing in 8 hours, like most of the latest FPS games just released.

I have yet to see any work go into high priority, but then I don't mess with it either and let BOINC do whatever it thinks is correct.

---

Will see tomorrow if I can reproduce latest ridiculous example of BOINC high priority overtake.

Okay then I won't produce some example. Still why could it not be an option for advanced BOINC users to switch this feature off?
The other feature, switching between applications, is one that can produce similar loss of work with work units that don't make saves or sporadically make saves. At least here we can use a workaround to put this in the options: "Switch between applications every 9999999.99 minutes"
Leave applications in memory while suspended is not really an option with projects like RNA World or Cosmology.
Why can't someone with enough experience of BOINC take some more control? I guess I am a control freak. :D

Edit: I am part of a group that switches between projects on almost monthly basis and some projects are added in case they have work (SIMAP, Lattice). This is also why we often encounter the unwanted high priority feature.

I think in theory the high priority function can suspend tasks and switch to others resulting that none of the tasks are finished before the deadline. High priority switching is often caused by BOINC not exactly knowing how much time is needed to finish tasks. I don't see the point actually, first in first out. Finish oldest tasks first, abort tasks that can't be finished before deadline. Switching to other tasks in high priority serves no purpose at all. I have seen a lot of cases when BOINC wasn't pressed and it started a new task that had the broadest deadline instead of starting the oldest task. Never mind, I asked.

Edit: Just crossed my mind, not everyone has x computers for DC purposes. I have only one 2600k, nice system. I also use it for watching videos, playing games, etc. I know people who use their laptop for same purposes. The "leave application in memory" option is not always a workable solution if the computer has to stay responsive.

Edit: I am part of a group that switches between projects on almost monthly basis and some projects are added in case they have work (SIMAP, Lattice). This is also why we often encounter the unwanted high priority feature.

If you're going from new project to new project then you will also encounter high priority more often. When I say new project I don't necessarily mean that the project itself is new, I'm referring to projects that you haven't crunched before. The projects estimate the fpops required to complete their wu's (some are good at this, others are not, some wu's are easy to calculate this for, others are not, and then there can be variations within the wu's themselves).

The estimate of fpops is then adjusted by the DCF (duration correction factor) which is basically a measure of the error in the calculated fpops compared to the actual fpops.

So when you are new to a project you have to rely on the projects estimates of time it will take, the longer you stay with that project, the more wu's you crunch, the more the DCF becomes accurate, but if you keep hopping from project to project...

---

CIC1=CC=C(C2=N[C@@H](CC(OC(C)(C)C)=O)C3=NN=C(C)N3C4=C2C(C)=C(C)S4)C=C1

These high priority features are causing an issue with projects that are providing work intermitently. It seems boinc is considering that it will continuously receive wus for this kind of project even if the project only delivers a few hours or even minutes of work per day.

More generally, the high priority feature may be an issue when mixing on the same hosts projects that are very different in nature or have different settings ( few units vs continuous production; short wus/dealdlines vs long wus/deadlines; very different share values; wu duration very variable, ... ) that could result either in difficulties crunching on the preferred project or missed deadlines for the big wu being crunched for days.

A good example of that is the project renderfarm.fi
A limited number of wus is available every day, generally during a short period of time they have a very short duration and very short deadline.

A good practise would be to put this project with a high "share" value in parallel with an other one providing work regularly so that as much renderfarm wus are computed in the less than 1h a day period when there are wus available and the other project is computed the remaining 23h.

Unfortunately, when the first renderfarm wu arrives, the boinc managers seems considering that it will receive such wus all day long and so put my other project in high priority mode despite the wus have much more time than needed to execute.

The only option I found is to suspend the other projects when I see some wus which, you will admit is a very bad solution and results in loss of power.

You have also the well-known example of the big wu at 99% after days of computation 99% mlost because of boinc misetimating the durations of the wus of an other project with short deadlines and lading too many wus.

I understand that the disabling totally the 'high priority' mode may cause other issues like if it stays disabled accidentally but it may be a good think to let the possibility to let the users put some wus or even some projects in 'very high priority' mode

1) keep all of the CPUs alloted to BOINC occupied with work
2) return results before deadline
3) over the longterm, divide system resources amongst the projects you run according to the resource shares you specify

SKIP

If you can provide an example of the scheduler failing to meet its 3 primary goals and none of the aforementioned "tricks and possibilities" fix the problem then we're interested.

I can. Although my issue was somewhat orthogonal. Just last Thursday (no, not "The Last Thursday") I'd babysat a client on three cores. Buffer is set to one day. However, for 12 hours or such client had kept buffer at something like 17Ksec (instead of 86Ksec).

My installation is somewhat weird, I understand that. I have to give network for client each four hours (via simple cron-job). Twice I suggested client to go for WUs, but in spite of having three WUs only (and one of them with estimated time some 200sec) client ignored network completely. Until one core would have been left with no WUs at all nothing could force client to get more.

So, my wish would be a button with nine red letters engraved on it:

GTFWUs NOW

OTOH, it's clear to me, any toggle that can force client to do something screws things even more.

---

I'm counting for science,
points just make me sick.

1) keep all of the CPUs alloted to BOINC occupied with work
2) return results before deadline
3) over the longterm, divide system resources amongst the projects you run according to the resource shares you specify

SKIP

If you can provide an example of the scheduler failing to meet its 3 primary goals and none of the aforementioned "tricks and possibilities" fix the problem then we're interested.

If there is a big difference between the highest resource share and the lowest resource share, the project with the low resource share will tend to run in high priority mode when it should not. In that case try reducing the difference.

So you admit this behaviour goes against goal 3)

Having wus with days or even weeks before the deadline entering in panic mode just because a few minutes of work for an other project was downloaded is simply ridiculous.

high priority is not supposed to happen on systems running 24h/day; boincmgr is not supposed to load more than it can eat.
Eevry panic mode is an evidence of something going wrong. It can be a wrong estimation of the wus duration, but in the example below it's simply boincmgr wongly statig that a lot of other wus will be downloaded.

If disabling high priority nor allowing "very high priority projects" cannot be allowed, please at least prevent wus from going in high priority when all what is actually downloaded can be crunched way before the deadline.

Having wus with days or even weeks before the deadline entering in panic mode just because a few minutes of work for an other project was downloaded is simply ridiculous.

Run with the <rr_simulation/> and, <sched_ops_debug/> <cpu_sched_debug/> flags on in your client configuration file, show this behaviour. Preferably in an up-to-date client. Showing it in 6.10 or 6.12 isn't up-to-date, the scheduler in those versions isn't going to be updated, ever.

And of course, since BOINC is open source, there's always the option to get the source code, tinker away at the scheduler all you want to make it do what you want, and then recompile the client running that code.

---

1) keep all of the CPUs allotted to BOINC occupied with work
2) return results before deadline
3) over the long-term, divide system resources amongst the projects you run according to the resource shares you specify

SKIP

If you can provide an example of the scheduler failing to meet its 3 primary goals and none of the aforementioned "tricks and possibilities" fix the problem then we're interested.

If there is a big difference between the highest resource share and the lowest resource share, the project with the low resource share will tend to run in high priority mode when it should not. In that case try reducing the difference.

So you admit this behavior goes against goal 3)

No it does not. The goal says "over the long-term". Eventually the scheduler will stop downloading work from the projects that run high priority and request work from projects that have not received their share. If a project does not get its share for a week, I don't see a problem with that. To me only the long-term matters.

You're advising to decrease the project resource share to have more work done on it; clearly against goal 3). The higher the share is the more work is supposed to be done on that project.

Over the long term what you will observe is the lowest resource share project vampirizing almost all available resources by jumping into high priority every time a single unit of the highest resource share project is downloaded even if the highest resource share project is only delivering work a few hours per day leaving more than enough time for the wus of the other project to execute and to meet their deadlines.

Let’s go back to the example and take a project called myfavoriteproject delivering short wus with short deadlines with work available only a few hours per day ( there are plenty of such projects.) and an other one called mydefaultproject delivering longer wus with much longer deadlines.
I would like boinc to :
1) Crunch as many as possible on myfavoriteproject when there’s work available
2) Crunch on mydefaultproject the rest of the time not to lose CPU power
What I am observing is exactly the contrary, mydefaultproject is crunched almost all the time going in high priority every single time a wu of myfavoriteproject is loaded.
The more I increase the share for myfavoriteproject, the less resources the more it gets stopped by the other project jumping into high priority and so in final the less resources it gets which is obviously totally the opposite of goal 3)
To go against that the only solutions seems to be either doing micromanagement ( suspend mydefaultproject when there’s work available on myfavoriteproject; release it after ) or even to crunch only on myfavoriteproject which you will admit results in a loss of power.