Is there a way I can make BOINC complete whole work units before switching applications? It just seems "messy" to me, for it to alternate between 4 different half-completed jobs.

The only control I can find over this is the "switch between aplications every ___ minutes".

I guess the problem would be that my current climate prediction unit lists 1096:27:24 to completion, and that might cause some of the others to fall just a tad behind. But I'd at least like to have it run entire blocks of the smaller jobs (like SETI and Rosetta), and not switch until they are complete.

Can this be done?

You can not but BOINC can, if certain events occur BOINC will run the smaller Projects;


Work Sechduler
EDF (earliest date first) is caused by:

1) A deadline within 24 hours.
2) A deadline within 2 * the connect time.
3) A failure of the Round Robin simulator to finish a result within 90% of its deadline.

A project not requesting work is caused by:
1) A host that is in NWF (no work fetch)
2) A project that has enough work on a host that has enough work.
3) A project that has a LTD that is negative enough.

NWF (no work fetch) is caused by:
1) A failure of the Round Robin simulator to get a result done within 90% of a deadline if the resource share of the next project to request work from is added to the Round Robin simulation.

Work will always be requested from somewhere, even if that somewhere has a very negative LTD and/or the host is in NWF (no work fetch) if there is a CPU that is idle and there is a network connection.


The report of work completed will be made at the earliest of:
A new work fetch.
24 hours before the deadline of a result (or immediately if the result finishes after 24 hours before the deadline).
Manual update by the user.
Contact for a trickle. (CPDN only so far).
Connect every X days after a result is completed.
This is done because remote procedure calls are moderately expensive for the server, and it is good to reduce the server load by doing several things at once

---

BOINC Wiki

The only control I can find over this is the "switch between aplications every ___ minutes".

Depending on the projects you're running _other_ than CPDN, and how long it takes your machine to do each, it _may_ be possible to at least reduce the number of "preempted" results you have sitting there.

Set the switch time to just a bit above what your longest 'reasonable' project takes. (I'm not including CPDN!) For example, if you're running SETI, Rosetta, and Einstein, and SETI takes just over 1 hour, Rosetta takes just under 2 hours, and Einstein takes 6 hours, I would suggest switching every 2 hours. (You could go 6, but that seems extreme.) After a few results have made it through, _if_ your debts are all real close to "equal", then it should recalculate which project to run every time one completes, find that the answer is not the same project as it _was_ running, and switch. When it's doing Einstein, that one will be preempted, but it should rarely preempt a Rosetta or SETI.

---

Oki, Thanks.

Bill,

Your advice is only completely true for systems with only one processor. With 2 or more CPUs (HT machines, cual core, dual processors, etc.) the CPU scheduler has a tendency to reschedule more than just the CPU that went idle.

Which, even though I have my setting to 2+ hours, still leaves me with a fair stack of work units that should have completed. I think JM VII is going to look at this in the next major go around (whenever that might happen).

---

Your advice is only completely true for systems with only one processor.

You are, as always, correct sir. Not having one at the moment, I tend to forget about multi-CPU systems. Easily corrected, of course - anyone with a spare G5 Quad, email me and I'll give you the address to ship it to... :-)

EDIT:: Trux has a client with processor affinity... wonder if that would make any difference?

EDIT again:: While I don't see this whole thing as a problem, it _is_ irritating to see a result at 99% or even 100% that is switched out, not to finally be finished for several hours (running several projects...) THAT is the part that I would be most interested in having fixed; "if % done > 98, don't switch unless something else is in deadline trouble".

---

While I don't see this whole thing as a problem, it _is_ irritating to see a result at 99% or even 100% that is switched out, not to finally be finished for several hours (running several projects...) THAT is the part that I would be most interested in having fixed; "if % done > 98, don't switch unless something else is in deadline trouble".

I remember a debate on a CPDN board, back in the BOINC beta days when some of us were wondering how this multi project thing was going to work, when precisely this problem came up. It seemed to me then one of the biggest objections to time slicing. Strange to think that was only back in 2004 :) The whole business of project switching has proved to be every bit as difficult as we thought.

---

As should be no surprise, it is also one of the hardest parts of an OS to get right. In my opinion, for example, windows still has a long way to go before it will have multi-tasking working well.

You can easily see that when you get focus stealing actions ...

Bill, if there is a loose Quad around here you are not going to get it ... :)

---

Actually, I fail to see the point of even attempting to switch exactly upon completion. Doesn't the work get done at the same rate, regardless. Of all the things that might need to be changed, I would put this near the bottom of the priority list.

---

"The arc of history is long, but it bends toward Justice"

Actually, I fail to see the point of even attempting to switch exactly upon completion. Doesn't the work get done at the same rate, regardless. Of all the things that might need to be changed, I would put this near the bottom of the priority list.

The point is that when the work is completed, that only that CPU that did the work should switch to a new work unit.

And, though the cost is minor, each time you switch, you have to spin up the models being started. So, on a 4 CPU system you could be changing models to run every 30 min or so even though you want to only do it on model completion or 2 hours (or more).

---

Actually, I fail to see the point of even attempting to switch exactly upon completion. Doesn't the work get done at the same rate, regardless. Of all the things that might need to be changed, I would put this near the bottom of the priority list.

Maybe, but if you change the goal slightly it quickly moves up the priority list. The goal should be to only switch at a checkpoint. This eliminates almost all lost CPU time due to changing projects without the overhead of leaveing applications in memory.

In some projects this can make a huge difference in performance because not all projects are able to checkpoint as frequently as SETI currently can. Some do not checkpoint at all.

---

BOINC WIKI

BOINCing since 2002/12/8