I have my WUs set up from different projects so that they rotate every hour to give each task an equal amount of time. However, when I attach some projects like Einstein and Climate Prediction, I see that the WUs from these new projects are running "high priority". How can I make them rotate normally so that they only spend an hour on each?

Thanks a lot. lol, I apoligize for the deception, it wasn't intentional.

I also have this problem -- I have two slower Linux machines set up (slow = one is a Pentium-MMX 233MHz, the other is an AMD K6-2 300MHz). When I attach to them with my BOINC manager, it says "Running, high priority" on whatever task it's working on. Now, the explanation Sekerob makes sense -- I'm attached to climateprediction.net on both machines. One machine is stuck doing a CPDN work unit, and the other, since it's freshly set up, is heading there after it gets done with it's SETI@home work unit. I've heard (from this post) that CPDN doesn't care about going over your deadline, so here's what I did. I'd appreciate it if someone double-checked me on this.

I went into client_state.xml, went down to the section that had my CPDN work unit, and went into the key labelled "report_deadline", and added 157788000 to the number that was there (5 years * 365.25 days per year * 24 hours per day * 60 minutes per hour * 60 seconds per minute = 157,788,000), and restarted BOINC.

It seems to have worked, as the BOINC manager now shows the work unit due in 2014 (instead of 2009), and it immediately downloaded a new S@H work unit and started working on that...except that it immediately started running the S@H work unit as high priority...

Ignore all of the "CPDN does not care". BOINC cares and will switch if it sees a job not getting completed in time, any job. If there is a solution in BOINC 6 i don't know.

The CPU scheduler in BOINC 6.2 is pretty much the same as it is in BOINC 5.10.

---

BOINC WIKI

Hi Matt

I'm from ClimatePrediction. It's true that the CPDN servers ignore the climate models' deadlines. Last year CPDN also lengthened the deadline for all types of model to give the BOINC scheduler and crunchers a better chance to distribute processing time more evenly between projects in the short term as well as the long term.

But this doesn't mean the CPDN researchers don't care about whether models are completed by the already generous deadline, or within a reasonable time after that, or 5 years after the deadline.

If you're attached to lots of projects and you lengthen the CPDN model's deadline, you're telling the BOINC scheduler to take all that extra time.

I would say it's very unlikely that the current versions of the three types of model will still be added to a useful research database in 2014. There are international norms and standards that the models have to comply with in order, for example, for research based on them to be used by bodies like the IPCC. A model that goes years past its deadline could be rejected for non-compliancy with future standards.

In addition, the longer any task is on a computer, the greater the risk that it will crash. Backing up the complete contents of the BOINC folder regularly is of course a way of reducing the risk that a model won't be completed as models can be restored and run from the restore point even after they've reported to the server as crashed.

Sometimes we just have to be realistic about the amount of work from different projects that a particular computer can do.

CPDN members can now select in their project preferences the type of model they want to download next. Anyone who hasn't got the resources for a model that will take 3 or 4 months to complete 24/7 should select a type that will take 2 or 3 weeks. And then perhaps set CPDN to No new Tasks for a while to contribute more to other projects. Though the scheduler will ensure that that happens anyway in the long term.

The BOINC scheduler is already super-flexible and CPDN model deadlines are not meant to be reset.

If you're attached to lots of projects and you lengthen the CPDN model's deadline, you're telling the BOINC scheduler to take all that extra time.

What adds into this is that if the project has an X weight / resource share, say 25%, the client will try to meet that commitment too, thus it is well possible that the jobs gets finished long before. But however it is twisted, soon as the client computes that 25%, against active frac and time remaining is not enough, will the CPDN or any other job go into high priority. That could return to normal of course once it's caught up in the back time. Thus, look at multi project clients' LTD and often times you'll find debt in the millions of seconds for CPDN. Call it a CPDN affliction of unsuitability to run in share time. The more projects, the worse it gets, BUT, with 2014 it should take longer for the condition to arise.

Yes, but extending the deadline may mean the result is useless to the project. Deadlines are there partly for real world reasons. While CPDN may be generous with tasks that run slightly over, having a task that is years past deadline will probably make all of the CPU time spent on it completely wasted.

---

BOINC WIKI

Wow...nice to actually hear from someone working on CPDN.

The intent here wasn't to have one computer crunch the same work unit for five years before returning it. The intent was to be able to allow these computers crunch work units for more than just CPDN. As I said, one computer had already gotten to the point where it was ONLY crunching CPDN units (and at high priority), the other one seemed to be going in that direction (seeing as it was slower than the first). I guess I just chose 5 years at random as a length of time that would have been likely to solve the problem -- which it did. Realistically, I probably should turn their due dates back to what they were, as the machine may have trouble finishing it by the actual due date without the extra workload.

one is a Pentium-MMX 233MHz, the other is an AMD K6-2 300MHz)

These are considered too slow to complete a climate model in a reasonable time; minimum should be about 1.6 GHz.
If the computers are that old, then they probably also have less than the recommended 512 Megs of ram that's considered to be the minimum to avoid constant model failures.

actual due date

= ASAP, not the BOINC deadline. Take too long with some of the model types, and the data will be of little use.

Wow...nice to actually hear from someone working on CPDN.

The intent here wasn't to have one computer crunch the same work unit for five years before returning it. The intent was to be able to allow these computers crunch work units for more than just CPDN. As I said, one computer had already gotten to the point where it was ONLY crunching CPDN units (and at high priority), the other one seemed to be going in that direction (seeing as it was slower than the first). I guess I just chose 5 years at random as a length of time that would have been likely to solve the problem -- which it did. Realistically, I probably should turn their due dates back to what they were, as the machine may have trouble finishing it by the actual due date without the extra workload.

The work fetch / CPU scheduler interaction is such that if CPDN uses 2 years of CPU time getting a task done, then it would not be getting work (unless your other projects ran dry) until the CPU time was paid back.

---

BOINC WIKI

one is a Pentium-MMX 233MHz, the other is an AMD K6-2 300MHz)

These are considered too slow to complete a climate model in a reasonable time; minimum should be about 1.6 GHz.
If the computers are that old, then they probably also have less than the recommended 512 Megs of ram that's considered to be the minimum to avoid constant model failures.

actual due date

= ASAP, not the BOINC deadline. Take too long with some of the model types, and the data will be of little use.

A 1 GHZ machine will do OK as long as you don't mind it doing CPDN for 9 months, and then doing other projects for a while until the CPU time is made up.

---

BOINC WIKI

Hi again Matt

I've now reread the specs you posted earlier for the two computers; what this really means for you is only now sinking into my brain.

I agree with John about computer specs for CPDN models but am going to expand on this a bit.

If you have an older lower-spec machine you're unlikely to be sent a relatively short HADAM model because if the computer hasn't got 1.5GB RAM, the server won't send one.

The HADCMs do as John says really need 1GHz minimum. With an 80-year model you might manage with slightly less, but you can't select whether the server sends you 80 or 160 years. You get what's next in the work queue.

The HADSMs are much shorter but even they take up to 3 weeks 24/7 on a modern computer. So I don't think that tackling them with much less than 1GHz is a very good idea either.

Matt, would you be able to move the climate models to a faster machine, which would also have to be Linux as you can't switch platform? If you have a faster computer that could run them (not necessarily immediately), you'd have to suspend them in the Tasks tab on the computers where they are now, complete and report all other work from all other projects and set the other projects to No New Tasks. You'd then have just a climate model left.

You could back up the complete contents of the BOINC folder to somewhere external, then restore the BOINC folder backup to a newer computer with no current project tasks on it and its BOINC folder deleted/emptied out. Reinstall BOINC and the model would complete, fast. You'd have to edit one xml file to allow the model to cope with the faster speed - we'd tell you the details.

After completing one model on the faster computer, you could then transfer the other. Moving a BOINC folder from one computer to another is quite quick and easy as long as you have some external storage device that both computers can see.

It wouldn't matter if you moved one model in three months' time and the other three months after that. The CPDN servers allow models to be completed on different machines.

If you are able to do this you could then keep the two older computers for projects with short tasks. Anyway, that's just a suggestion in case you have the resources.