I have recently started processing MW@H wu's, in addition to two other BOINC applications. I am using a Dell computer with a 2-core processor. My computing preferences are set so that each of the three applications should have a 33.33% resource share, and that there should be a switch between tasks every 60 minutes.

However.... One a MW@H wu starts being processed it will not switch to another task, with the result that the other 2 applications are getting no processor time at all.

Is this behaviour on the part of MW@H normal? or have I missed a switch which would control this power grab?

Any assistance on this will be gratefully received.

I have recently started processing MW@H wu's, in addition to two other BOINC applications. I am using a Dell computer with a 2-core processor. My computing preferences are set so that each of the three applications should have a 33.33% resource share, and that there should be a switch between tasks every 60 minutes.

However.... One a MW@H wu starts being processed it will not switch to another task, with the result that the other 2 applications are getting no processor time at all.

Is this behaviour on the part of MW@H normal? or have I missed a switch which would control this power grab?

Any assistance on this will be gratefully received.

Yes it is normal and no you can't really do anything about it without constantly micromanaging it, which in the long run won't really do anything except make you go crazy. This has long been on the to do list, but too many other things keep coming up that push it back down again. Boinc will automatically switch back and forth between your 3 projects using a complicated formula and deadlines to try and keep your 33% numbers. If you track it over the next few months by the end of that time you should be pretty close to the 33% for each project mark. BUT in the short run, ie today or even this week, the numbers will probably be skewed towards one project, or away from one of the projects.

One of the keys is the deadlines for each project, some projects have very short deadlines, some have very long deadlines. This creates problems for Boinc, then depending on the size of your work cache you could be creating even more problems too. Try and keep your work cache around a days worth and you should find the 33% number closer, but never exact, as Boinc itself can then just crunch and not have to worry about the deadlines so much.

Thanks, Mikey

I thought that I had done something wrong. I will wait a month or two to see how it pans out.

Martin,

Mikey is right that sometimes one of your projects will play catch-up, and you will see two processes from the same project running on your two cores.

However, you should also be aware that if you are running N-Body tasks those are (usually) multi-threaded, so if one of those starts up it will utilize both your cores.

So, N-Body tasks grab the whole machine, but the other two types of Milkyway job can share your machine with one other project's process...

Happy crunching!

Alan

I was aware that the N-body tasks took over both cores. What I was really worried about was the fact that they did not release after the 60 minute period, when tasks were scheduled to switch. I just wanted to check that this behaviour was normal, and Mikey assures me that it is. No further problems......yet.

Alan

I was aware that the N-body tasks took over both cores. What I was really worried about was the fact that they did not release after the 60 minute period, when tasks were scheduled to switch. I just wanted to check that this behaviour was normal, and Mikey assures me that it is. No further problems......yet.

Yup it sounds like deadlines are killing you right now, I suspect the short MW deadlines aren't letting the units switch. I would lower your overall cache size and see if Boinc doesn't start downloading fewer units from each project, but swapping back and forth at the 60 minute mark.

The next thing you will see is checkpointing, when a unit stops so a different one can then startup the old unit sets a checkpoint, the problem is the last checkpoint could be 15 minutes ago. So when you do come back to that unit you go back in time 15 minutes and start over from there. This is ALSO common in Boinc and the checkpoints are the only way people can run multiple projects on one pc at the same time using the same resources.

That's why some of us have gone rogue and have multiple pc's, so we can run multiple projects but only have one project at a time running on each pc. The other reason to have multiple pc's is to focus on one project giving it alot of resources. I personally do a bit of both.

Yup it sounds like deadlines are killing you right now, I suspect the short MW deadlines aren't letting the units switch. I would lower your overall cache size and see if Boinc doesn't start downloading fewer units from each project, but swapping back and forth at the 60 minute mark.

On my machine there hasn't been a switch away from the current nbody task for over 7 hours using the 6 out of 8 cores I've allocated to Boinc, even though another project that has unfinished tasks has a nearer deadline. It quite puzzling - as if these tasks are programmed to prevent other tasks running.

- Richard.

Yup it sounds like deadlines are killing you right now, I suspect the short MW deadlines aren't letting the units switch. I would lower your overall cache size and see if Boinc doesn't start downloading fewer units from each project, but swapping back and forth at the 60 minute mark.

On my machine there hasn't been a switch away from the current nbody task for over 7 hours using the 6 out of 8 cores I've allocated to Boinc, even though another project that has unfinished tasks has a nearer deadline. It quite puzzling - as if these tasks are programmed to prevent other tasks running.

- Richard.

It's just an overly-complicated programmatical thing that BOINC does. (is programmatical a word?) BOINC runs benchmarks to see how fast your processor is, so it does its best to get tasks reported on time. If BOINC thinks a task is nearing the deadline, it'll run those tasks at "high priority" and say so in the manager.

Just throwing out an example, Collatz Conjecture was a project of the month for my team. When I re-attached all my other projects a few days ago with every project at the same resource share, the work buffer filled with just one project. After a while (maybe the hour switch?) another project filled the buffer, and so on.

From what I've seen, it's best to let BOINC do its thing. The 'switch applications every 60 minutes' doesn't seem to work all the time, and it doesn't necessarily mean switching tasks. (there's a difference between tasks and their applications) And even though my resource shares are all the same, I think BOINC tries to get the same crunch rate for each, which is why Collatz hasn't had any tasks for a few days because it already had a lot of crunching done.

---

Yup it sounds like deadlines are killing you right now, I suspect the short MW deadlines aren't letting the units switch. I would lower your overall cache size and see if Boinc doesn't start downloading fewer units from each project, but swapping back and forth at the 60 minute mark.

On my machine there hasn't been a switch away from the current nbody task for over 7 hours using the 6 out of 8 cores I've allocated to Boinc, even though another project that has unfinished tasks has a nearer deadline. It quite puzzling - as if these tasks are programmed to prevent other tasks running.

- Richard.

Boinc does internal calculations, using the benchmarks SuperSleuther talked about, and SHOULD switch when it thinks it has too. Right now it thinks it's okay, it's 'recalculating' all the time though so it could switch at any moment.

Boinc does internal calculations, using the benchmarks SuperSleuther talked about, and SHOULD switch when it thinks it has too. Right now it thinks it's okay, it's 'recalculating' all the time though so it could switch at any moment.

OK, well we'll see how it goes. As I write this the same task has been running uninterruptedly for 14.5 hours with a deadline on 12th, while there are 5 other tasks for another project the deadline for which is the 5th.

- Richard.

Martin -

To add what has already been said - You have three projects with a LONG TERM goal of 33.33% of your computer power allocated to each. You have over 120,000 credits on Cosmology and something like 2,700 credits for Milkyway. It just makes sense that BOINC is going to spend a LOT of time processing Milkyway work until Milkyway "catches up".

"It just makes sense that BOINC is going to spend a LOT of time processing Milkyway work until Milkyway "catches up". "

And that has been one of my major gripes about the scheduler for quite a while

I really don't care what the total credits or recent averages are

When I set 33% resource share for a project, what I expect is 33% FROM THAT POINT FORWARD, until I change it

(I do agree that micromanaging tends to create a lot more headaches than it fixes, tho)

---

"It just makes sense that BOINC is going to spend a LOT of time processing Milkyway work until Milkyway "catches up". "

And that has been one of my major gripes about the scheduler for quite a while

I really don't care what the total credits or recent averages are

When I set 33% resource share for a project, what I expect is 33% FROM THAT POINT FORWARD, until I change it

Unfortunately the Boinc Programmers see it differently and it just is what it is right now. The current process has evolved to what it is, it may evolve the way you like in the future, but we users have no control over that process.

(I do agree that micromanaging tends to create a lot more headaches than it fixes, tho)

One way to kinda sorta do it both ways is for you to suspend all but one project in a round robin fashion for a week each. That way over 3 weeks you WILL put 33% of your time in at each project, essentially overriding the Boinc settings. But again my kinda sorta solution is micromanaging.

"It just makes sense that BOINC is going to spend a LOT of time processing Milkyway work until Milkyway "catches up". "

And that has been one of my major gripes about the scheduler for quite a while

I really don't care what the total credits or recent averages are

When I set 33% resource share for a project, what I expect is 33% FROM THAT POINT FORWARD, until I change it

(I do agree that micromanaging tends to create a lot more headaches than it fixes, tho)

I don't know for sure (and every project is a little different) but I think BOINC credit is something like work done times the time it took equals how much credit. (the exceptions are projects like Bitcoin Utopia that give out way too much credit) Because credit is usually based on how much work is done, BOINC might be trying to use that to give an equal amount of scientific data to each project, which is different from just giving the same amount of processing time.

---

I don't know for sure (and every project is a little different) but I think BOINC credit is something like work done times the time it took equals how much credit. (the exceptions are projects like Bitcoin Utopia that give out way too much credit) Because credit is usually based on how much work is done, BOINC might be trying to use that to give an equal amount of scientific data to each project, which is different from just giving the same amount of processing time.

http://boinc.berkeley.edu/wiki/Computation_credit

It should average out to credit distribution, but there are a lot of factors that affect it, such as work dry spells, changing priorities and preferences, etc. BOINC will do the best it can, but I doubt anybody gets a perfect distribution unless they've not touched anything since installing BOINC.

---

Click here to see My Detailed BOINC Stats