Remember that you cannot compare frequency of WU per project against the Run Time per project. If you get a 4 hour WU from one project twice as often as an 8 hour WU from another project, then the scheduler thinks you are getting the same time.

WCG won't actually set CEP and Flu to Complete (or in the case of flu, Intermittent), until all the WU's that are currently being crunched have been returned. CEP is nearly there, whilst there'll still be some Flu WU's floating around the system for a couple of weeks (WU's that have passed their due date, errored out or become inconclusive etc.).

Meanwhile, CEP was always set to a lower priority than the other projects - basically due to the size of file they sent back (they were HUGE), thus, causing an issue with disc space. As to Flu, I believe that this was also a project 'restricted' in size - due to similar issues.

There are a few more complexities to assigning the logic that matches work to computers:

1) BOINC doesn't store your history of contribution to a specific research application. As a result, this cannot be factored into the match-making logic. We plan to add this someday, but that is at some point in the future.

2) There is a cache of jobs ready to be matched with computers. Only the jobs in the cache are checked for suitability to send to your computer. The only control we have on distribution is the relative proportion of results ready to send. Since the projects all have varying duration and the duration varies over time, this ratio has to be periodically adjusted as average runtimes vary to keep things 'fair'.

The cache also 'interleaves' the results in an array. Thus the array would contain:

faah
dddt
hcmd2
hpf2
rice
cep1
....
faah
dddt
hcmd2
....

the interleaving accounts for the different weights (i.e. it might go hcmd2, faah, dddt, hcmd2) to account for the higher number of results sent for hcmd2

3) For a particular user, as a request comes in the following logic is run:

• If the host is a reliable host, then scan for jobs that need to be processed by a reliable host
  
• If the host is willing to accept beta work, then scan for jobs that are beta jobs
  
• Look for jobs that have been marked as infeasible by scheduler request from another computer (i.e. another computer couldn't run it because it didn't have enough memory or disk space or because the hr class on the job was set to a different platform)
  
• Look for any available job
  
• If no work was assigned, and the user will accept work from non-preferred projects, then look for work from any project
  

Note that in all cases (except the last) only projects that the user indicated they want will be considered.

The biggest one here is the infeasible check. Projects like Help Conquer Cancer that run with redundancy and use the homogeneous redundancy logic enabled for the project have a lot more jobs ready to send that are already allocated to a specific hr_class. This means that they are more likely to be assigned to a computer then a job from a project like Nutritious Rice that doesn't use homogeneous redundancy. As a result, Rice has to be given a higher weight to make up for this effect.

The overall thing I'm attempting to explain, is that there are a lot of factors in addition to user preferences that affects the overall runtime that a project gets. As a result, we have to weight the projects to keep things on an even basis.

At some point I would like to query the database and look at the user preferences and measure that against their contribution and be able to deduce the desired overall contribution ratio. At the moment though, this data is locked up in XML documents stored in varchar fields. At some point we will switch that so that we can use xquery to get at the data, but for now we cannot.

I hope this helps folks understand some additional things about how the BOINC scheduler works.