I understand with BOINC that we can participate in several projects at the same time. However, at the present time, BOINC will only work on a single project at a time. Even if you set Project1 (ie SETI) at 200 in the preferences for resource share, and Project2 (ie Beta) at 100, Project1 works at 2/3 and Project2 works at 1/3. I would think it would be processing both projects at the same time, alloting 67% CPU to SETI and 33% to Beta, but that is not the case. It gives 100% to SETI (under the 'work' tab). It only works on 1 WU at a time and then moves on to the next one. Why doesn't it process WU's from different projects simultaneously? I thought this was the main purpose of BOINC?

No, the concept was never to process multiple project simultaneously. This wouldn't be very effecient, and there really isn't a way to divide CPU cycles like that.

BOINC processes WUs from different projects in sequence, not simultaneously. It decides which project to fill the queue from based on the resource debt which is based on the current value of the exp_avg_cpu, and the resource share specified for each project. When starting a new project, it is expected that the new project will get the lions share of work, as it has no average CPU usage, and has to build it up a bit. However, if either project has work, then work will be downloaded from one of them, even if it is not the current preferred project.

Hm, the inability for BOINC to "multitask" creates some limitations to what kind of projects the user can participate to. For example, the climate prediction project (http://www.climateprediction.net/) is very CPU intensive when considering the amount of time it needs to complete a climate model, 2 to 4 weeks on an average speed computer, so by this time, all the other projects will have their WU's to become obsolite because it takes too long for them to be completed within the two week timeframe.

If BOINC would multitask, this wouldn't be a problem, since all of the projects would process at the same time. Now only the "top notch" computers can do all this, since they're fast enough, but what about the users without so fast hardware?..

We have a few project options less to participate to.

regards

--J

> If BOINC would multitask, this wouldn't be a problem, since all of the
> projects would process at the same time. Now only the "top notch" computers
> can do all this, since they're fast enough, but what about the users without
> so fast hardware?..
>
> We have a few project options less to participate to.

Give Predictor a try. It's WUs are pretty quick.

> Hm, the inability for BOINC to "multitask" creates some limitations to what
> kind of projects the user can participate to. For example, the climate
> prediction project (<a> href="http://www.climateprediction.net/">http://www.climateprediction.net/[/url])
> is very CPU intensive when considering the amount of time it needs to complete
> a climate model, 2 to 4 weeks on an average speed computer, so by this time,
> all the other projects will have their WU's to become obsolite because it
> takes too long for them to be completed within the two week timeframe.
>
> If BOINC would multitask, this wouldn't be a problem, since all of the
> projects would process at the same time. Now only the "top notch" computers
> can do all this, since they're fast enough, but what about the users without
> so fast hardware?..
>
> We have a few project options less to participate to.
>
> regards
>
> --J
>
I disagree. You only have one queue, not one per project. When your queue is nearly empty and you download a CPDN WU, the other WUs will finish before the CPDN WU is started because the cache empties in order of deadlines. Once the CPDN WU is started, your queue will not get work until the CPDN WU is nearly finished (based on the low water mark that you set). The only place where the developers and I disagree about this is I believe that the queue should be strict First In First Out due to possible problems with multiple CPUs and starvation of a long running WU. But this scheme will work well on single CPU systems.

I always understood it to spend 2/3 of the time working on one project's WU's, and 1/3 of the time would it be working on the other wu's. so it would complete 2 seti's, then 1 of the other.
it could never do 2 at the same time... that would waste cycles and cpu power

> I always understood it to spend 2/3 of the time working on one project's WU's,
> and 1/3 of the time would it be working on the other wu's. so it would
> complete 2 seti's, then 1 of the other.
> it could never do 2 at the same time... that would waste cycles and cpu power

No, it will complete all the S@H WUs it downloaded, then work on the other project.

Many of you seem to think multitasking is inefficient and a waste of CPU time.. want to explain why?

--J

> Many of you seem to think multitasking is inefficient and a waste of CPU
> time.. want to explain why?
>
> --J
>
Multitasking is inefficient because the entire working set (data and instructions) must be moved out of the CPU and back in from memory when tasks are switched. While this must be done to make a computer respond to the real world reducing the number of swaps will improve total output. A low priority task (seti) is more likely to get swapped out to begin with. If you add another equal priority task the number of swaps will more than double. Each swap will cost 2 to 20 CPU cycles depending on exactly where in cache or memory the data has to go/be retrieved from. If the data has to be sent or retrieved from disk it may cost hundreds of cycles.

Running workunits sequentially enables an unlimited number of projects to be run on one computer, even the slowest computer capable of running the individual projects. If they were being run concerently there would be a hard limit on how many projects could be run on one computer since each additional project would raise the real time needed to process a workunit. Add enough projects and even the fastest computer would not be able to finish any of them in time.

John Keck
BOINCing since 2002/12/08