Posts by darealgh

1) Message boards : BOINC client : Being able to switch off high priority feature of BOINC (Message 41607)
Posted 12 Dec 2011 by darealgh
Post:

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.
2) Message boards : BOINC client : Being able to switch off high priority feature of BOINC (Message 41567)
Posted 10 Dec 2011 by darealgh
Post:

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.
3) Message boards : BOINC client : Being able to switch off high priority feature of BOINC (Message 41522)
Posted 7 Dec 2011 by darealgh
Post:
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




Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.