Hello Kremmen,
That is definitely not the way BOINC is currently set up. After we switch over to all-BOINC and upgrade our DB version, knreed would have to write some programs for the scheduler (WCG-specific) and make some additions to the website. We already have a long wish list for him to try to put into the new server software, as and when time becomes available.

I don't think this will be done anytime soon

Lawrence

This is a problem with AC@H, which only has 820 WU every once in awhile, plus error reruns. It works well with two projects (AC@H plus something else), to keep it busy in the meantime.

To run one project, I can fill the queue with three days worth of a preferred project and not ask for other projects.

I watch every day or so to make sure it stays full.

There was a recent problem with FAAH, and nothing from any project was getting through, but I had enough work to get me through the bad day without asking for projects other than one I was working on. If it had gone on, I would have.

Kremmen,

The currently scheduler for BOINC has some limitations based on how it was originally written. At the BOINC workshop in 2007 there was a lot of discussion about this and there was a design sketched out on how to replace the simpler version of the scheduler with a more advanced host-workunit matching mechanism.

The current mechanism for sending work to a computer works (simplified explanation follows) by starting at a random workunit and then checks to see if the computers meets the requirements and if the user is signed up for the app. If the answer is use, the workunit is sent to the user. If not, then go on to the next workunit. This process repeats until the work request is satisfied.

David Anderson is looking at starting to implement these changes. The first version of this will replicate the existing functionality within the existing framework.

The new framework will again start with a random workunit but instead of making a binary decision, it will assign a score to the result for its fitness for execution on the computer. It will then examine the rest of the workunits in the memory cache and also assign them a score. The workunits with the highest score will then be assigned to the computer.

Once this framework is in place, it opens up the ability to look at adding new code to do as you suggest (assign a weight to our applications within a project) or new features such as allowing users to specify the amount of data to download at most X MB of data per week (the new framework would then give a bias to workunits with high cpu time/data ratios as the limit is approached).

These changes are going to take awhile to be implemented. However, progress is being made in this area.

Kevin

Good point. Some of my machines might be off for days/weeks, so I've tended not to queue work up, so that I don't have to abort WUs or leave them never completed. However, for the machines that will be on all the time, I should do exactly as you suggest.

The 'hard' limit for RAM for AfricanClimate@Home is 500MB. Make sure that you have set your profile so that it allows 100% of your RAM to be used if you want the 512MB computer to be able to get work from the project.