Ok this is going to sound like a repeat to many who read most of it in the Gripes and Kudo's thread but I was advised to start a new thread about it in there so thats what I'm doing.

My original post was:

My gripe is about job deadlines being so far out that they have about 2 months to run and yet for some reason BOINC seems to think that SETI needs to have priority and gives them higher priority to run than other jobs on my task list which are due in the next day or two.

Don't get me wrong, I love doing tasks for SETI both at home & Beta@home, but it seems totally ridiculous to me that when its June 1 for instance and tasks for SETI have a completion date of July 28 BOINC runs them first and completely ignores tasks that have a due date for other projects that are supposed to be completed in the next day or two in favor of tasks that aren't due until say July 28.

I don't get it.

I tend to put these tasks on suspend until about 3 weeks before the deadline which still gives them plenty of time to run before their deadline but I know that I have heard people grumbling about tasks not getting run and waiting for them to come in...but if the actual deadlines were realistic and were not so far out in the future, I would not suspend them like I do.

I had a batch of tasks due Jul 28 that I just took off hold yesterday due Jul 28 that haven't even started running yet and just tonight I got new tasks for Seti that have a due date of 8/17, 8/19, & 8/20 so I have suspended these tasks.

Ok, thats my gripe and grumble...Maybe you can explain to me why you use such long completion dates when the tasks seem to get such high priorities for completion anyway so I can at least understand that. Thanks.

and the reply made to me was:

(sorry copy/paste didn't maintain the quote effects)

I don't get it.

You set the manager to do certain percentages of work between projects, it tries to meet those requirements, and project deadlines.

I tend to put these tasks on suspend

And that is the sort of thing that results in the manager doing the things you're describing.

Maybe you can explain to me why you use such long completion dates when the tasks seem to get such high priorities for completion anyway so I can at least understand that. Thanks.

For more information, start a thread about the issue- this one is for Gripes & Kudos.
____________
Grant
Darwin NT.

~~~~~~~

So yes, I would like to know more about the long dates for job completion as I don't have this kind of thing happening with other projects and Seti is the only project that I seems to have this happen on. The answer that you gave me doesn't really explain to me why this occurs. If you are going to be given priorities by BOINC that allow the project to run ahead of other projects even though your deadlines are still close to 2 months away it doesn't seem fair to other projects that have deadlines that are much closer. But if there is a reason to run the projects ahead of others that is valid that explains why the priority then maybe I will stop putting the tasks on hold and just let them run however it still doesn't explain why you give such far out completion dates assigned by the project. I would just like to understand as it frustrates me when the project has deadlines so far out and comes in and stops other project with deadline dates in the next day or two to completion to run when they aren't due for a month and a half or two months yet.

And by the way, Seti and Seti Beta are the ONLY projects that I am doing this putting tasks on hold business on - its not a problem on any of the other projects and I am participating on almost every active project on BOINC.

BOINC runs FIFO(First In First Out) by default. Based on the estimated To Completion time of the other tasks BOINC will switch to the other projects tasks with a shorter deadline if it thinks their deadline will be missed.
You can force BOINC into High Priority mode by bumping up the "Maintain enough tasks to keep busy for at least" value for your queue. However, While the queue is processing tasks in High Priority mode it will not download new work.

Another issue is that BOINC tries to maintain the resource share you have set for each project. So if you have not done must work for one project for a while BOINC will want to run that project at a high priority to clear out it's debt.

EDIT:
Also some projects may choose to have a shorter deadline for a few reasons. Their project needs the data back more quickly or they only want hosts with higher processing power to participate. SETI@home has longer deadlines to allow slower hosts to be able to contribute.

---

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

No worries...LOL.
Dr. Anderson does not understand them either....

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

SETI@home of course has about a 15 year history, and some of the systems which started crunching in the early days are still in use. That's the main reason the deadlines are long, they are intended for hosts down to about 40 MFLOPS capability for SETI@home v7 tasks (Astropulse tasks have a higher minimum). Some of the new systems with high end GPUs are more than ten thousand times faster, but BOINC is supposed to adapt.

The design of how scheduling is now supposed to work was described in 2010 at http://boinc.berkeley.edu/trac/wiki/ClientSchedOctTen#Proposal:credit-drivenscheduling]. If that were working perfectly, over a period of a year or so the share of credit accrued for each project would match the relative resource share set for the project. Relative RAC might also correlate with the share settings, but different credit granting methods and its shorter term focus would cause variations.

Your host 6707917 is doing a large number of projects, some of which probably have only CPU applications and others with only GPU applications. Scheduling can appear unreasonable unless its estimated credit basis is considered. The actual implementation may also not achieve the design goals and/or have bugs, of course.

                                                                  Joe

SETI@home of course has about a 15 year history, and some of the systems which started crunching in the early days are still in use. That's the main reason the deadlines are long, they are intended for hosts down to about 40 MFLOPS capability for SETI@home v7 tasks (Astropulse tasks have a higher minimum). Some of the new systems with high end GPUs are more than ten thousand times faster, but BOINC is supposed to adapt.

The design of how scheduling is now supposed to work was described in 2010 at http://boinc.berkeley.edu/trac/wiki/ClientSchedOctTen#Proposal:credit-drivenscheduling]. If that were working perfectly, over a period of a year or so the share of credit accrued for each project would match the relative resource share set for the project. Relative RAC might also correlate with the share settings, but different credit granting methods and its shorter term focus would cause variations.

Your host 6707917 is doing a large number of projects, some of which probably have only CPU applications and others with only GPU applications. Scheduling can appear unreasonable unless its estimated credit basis is considered. The actual implementation may also not achieve the design goals and/or have bugs, of course.

                                                                  Joe

Your explanation also makes a couple of assumptions, two which are never true. The first being that every project has work available when asked for. We all know there are many projects out there that have work available only is a "burst" mode. That upsets the %'s. The second assumption is that BOINC is able to run a task when it wants to. On some systems buried in the log file might be a message "waiting for virtual memory" or some other warning message. This also upsets the %'s. Third assumption is that all work units are about the same length. We know they are not, so the %'s will under or overshoot because of this.

I've seen cases where BOINC asked a project for enough work to fill a hole in the schedule but got 10X that work with a short deadline and everything goes to hell in a hand basket. That filler unit is now in EDF mode and other work may not make deadline.

---

Gary, I agree that there are circumstances which BOINC will find difficult or impossible to handle. That's why I suggested it would probably work more or less as designed over a time period of a year or so. Assumptions behind that statement were that an interested participant could somehow restrain the impulse to make changes, and that the chosen projects don't die or change much over that period. Dr. Anderson's thinking is also assuming that a user will leave the default cache settings of 0.1 days minimum and 0.5 days additional and the host has 24/7 internet connectivity. In combination, those should make missing deadlines very unlikely.

I intended merely to present some background on the underlying logic of BOINC, not to endorse or explain it. I haven't investigated the source code in any depth nor am I using a recent BOINC version with the implementation.

                                                                   Joe

Thank you for the explanations. THey have helped me understand more about how the overall system works.