I'm really curious about how the ordering of tasks actually works.

The image below shows what I mean - despite there being several boincsimac tasks that are almost complete, BOINC just started a new task, which doesn't make sense to me. I'm puzzled (and impatient as I've been waiting for the 99% job to finish), and wonder if anyone can throw any light on this?

---

I shoot cancer (686 Magnum)

I'm really curious about how the ordering of tasks actually works.

If you really want to know boinc's way of scheduling you should read the source.

OTOH, I once observed (upon joining yet another project, and that project is a bit difficult) that a WU, what potentionally could take ~90min, had been started ~120min before deadline. I had very uneasy feelings about that (what if power blackouts, network outages, or WU would take more time?). In your case boinc thinks that it would have time to complete that '*.083117_*' and '*.078596_*' too. Now boinc thinks it should give more time to other projects (all of them are probably equally balanced).

Look, you really can't do anything about this except manually suspend-resume them. And why would you need boinc in that case?

plz, consider two things. It doesn't really matter if those 26sec would be achieved right now or 2h later. And,.. You terrorize boinc, then boinc frightens you; it's a balance.

p.s. Those WUs had been completed before deadline, hadn't they?

---

I'm counting for science,
points just make me sick.

When you run multiple boinc projects, the boinc client rotates the execution from work unit to work unit based on the projects' resource shares and the duration you have set in your preferences, typically 60 minutes.

In your case, the SIMAP WU had processed for 60 Minutes and the boinc client switched to another project.

If you want one project to have preference over all others, go to your account page on that project and raise the resource share to something higher. I have 2500 set for SIMAP, 1250 for most others, and 625 for low priority projects.

Crunch on!

---

When life hands you lemons, stick some nails in them and wire them up to power a DC rig.

It seems to be generally accepted that the BOINC scheduling does not work very well. I think you are experiencing an example of this. I run climateprediction.net and World Community Grid and I have to continually suspend a particular wu from climateprediction.net as the scheduler keeps running it high priority over my WCG work units even though I can see that the WCG work units will not be completed in time if I allow BOINC to do the scheduling and the cimateprdiction.net wu has just under a year to complete and has done 24% of the unit in under three weeks.

Completely incongruently it does not schedule another climateprediction.net wu to run even though that has a near identical deadline, more hours to run, and is only 17% of the way though!

Hopefully, later versions of BOINC will correct this deficiency which seemed to have been introduced about a year ago.

---

That's dreadful. The scheduler is supposed to give highest priority to the completion of tasks on time regardless of which project they come from. This should have higher priority than keeping the resource share balance between projects correct (as this can be corrected later).

Do you need to upgrade your Boinc to get a more recent version of the scheduler?

It seems to be generally accepted that the BOINC scheduling does not work very well. I think you are experiencing an example of this. I run climateprediction.net and World Community Grid and I have to continually suspend a particular wu from climateprediction.net as the scheduler keeps running it high priority over my WCG work units even though I can see that the WCG work units will not be completed in time if I allow BOINC to do the scheduling and the cimateprdiction.net wu has just under a year to complete and has done 24% of the unit in under three weeks.

Completely incongruently it does not schedule another climateprediction.net wu to run even though that has a near identical deadline, more hours to run, and is only 17% of the way though!

Hopefully, later versions of BOINC will correct this deficiency which seemed to have been introduced about a year ago.

Actually I found the Boinc scheduling works fairly well as intended. The problem is with the long CPDN work unit. CPDN doesn't share well with other project especially on single core machines unless you give it a major share of resource. The deadline may be far away but Boinc calculates how much CPU time it will need to make the deadline. Even with multicore you should generally avoid having more than one CPDN WU unless it is your primary project and give it a relatively large share of resources. On my Core 2 and i5 with around 14 active projects and CPDN with a 7% RS CPDN rarely goes HP for more than a couple of hrs mostly when I first DL it. I also keep CPDN in NNT so I only have one WU on the system at a time. I also run the system 24/7. If you keep suspending it you are only delaying its need to run and making the problem worse.

Your problem is probably that you have 2 CPDN on the system which double its need for resource share.

---

Boinc V 7.4.36
Win7 i5 3.33G 4GB NVidia 470

If in your CPDN project preferences you only select the shorter model types, currently FAMOUS and HadAM3P regional (EUR, SAF and PNW), and say you don't want any other type you could avoid much of this problem. If before downloading a new model you ask on the CPDN forum which is the shortest type available, someone will tell you. But find out first whether your computer has SSE2 or only SSE. The Boinc manager messages tell us this about the CPU, near the top. Some model types need SSE2, others don't.

I run 6.10.56 on a dual-core under XP, crunching mainly WCG/HCMD2 with a very small share to other projects like POEM, ibercivis, etc - 24/7.

All of the HCMD2 units I've received have a standard 10-day deadline, none have been prioritised.

In the past 24 hours or so,but not for the first time, I found that a HCMD2 unit had been switched to Waiting while two units with LATER due/sent dates (always 10 days' difference) were being crunched.

It would appear that this situation was triggered by the completion of one unit. This unit ran for 9hr40 on a nominal 6hr unit. Its running-mate went to Wait and two entirely new HCMD2 units were selected to run - but not the next two units in any apparent logical queue. There were twenty-two other HCMD2 units with earlier sent/due date-times (I only currently run HCMD2 units from WCG, not WCG's other sub-projects)

VERY shortly thereafter, a POEM unit got a look-in for literally a couple of minutes, THEN yet another HCMD2 unit was started and the POEM unit Waited. This latest HCMD2 unit was twentieth in the logical (FIFO) queue of HCMD2 units.

According to BOINC manager, Switch Between Applications is set to 750minutes.

I upgraded to 6.10.58 with no apparent difference - the units that were running continued on re-start.

All of which is fairly odd in my view. I would have expected that tasks would be executed in FIFO order within a project, even if there is some switching between projects, and switching between tasks for a single project within minutes (literally 10 minutes max) seems to make a nonsense of the 'switch between applications' setting.

It's been suggested that BOINC may like to 'taste' some units before deciding which order to run them - but having sampled the due-later units, it seems odd that they would usurp similar units from the same project.

In the past few minutes, the second HCMD2 unit from the 'running unexpectedly early' group has finished. The two units now running are the earliest-of-all which was Waited in the first instance and a 'running unexpectedly early' unit which was Waited by the POEM excursion. Both are simply 'running' whereas they'd been 'Running High Priority' throughout this period of aberration.

Not that it's really anything more than a curiosity - but I've observed it before and others have had similar comments.

No doubt all of the units will complete within their deadlines - but running due-later units does put that at risk given the possibility of blackouts or loss of communications. Not as safe as running pure FIFO, I'd say...

[/b]