Largely the mix is influenced as to what goes to [leftover] pool. If FAAH is substantially an 'exclusive' project as is DSFL, then that would be what you're observing.... both rather scarce in the pool, so coming down for you in fairer share. Per knreed the DSFL share is still set to low, little left to pool. That said, Clean Water are rather short, i.e. there are more going around, but still if currently that mix of CW and DSFL is chosen, no DSFL are coming through [observed for a 24 hour period, hence the micromanaging]

It's not as simple as it seems, but the techs are playing the fair share [total CPU time] and than each week look at the mean run times, then tell the distributor how many go into that X CPU years per project. Probably it's done manually as to prevent the system to go haywire when suddenly the mean times drop or skyrocket, torquing off or flooding, when there's not enough on the shelfs i.e. it's a safety so that on the forward, supply of any one science does not end up being drained or clogged, which could lead for 'exclusive' crunchers with no ''send me something else when dry'' selected to turn idle [or fetch work outside WCG] ;D

Sort of.

[VOT] A thought that crossed recently, but not proposed in the appropriate place was that maybe if we could have a quantity selected for all sciences same as CEP2, everyone would be able to get the mix and match. When all these slots are filled and the cache still not to the brim filled to send the random from the selected projects. Could have an impact on the scheduler, or maybe not, don't know what is tracked in terms of mix for each client. Think that the amount of visits to the device profiles would increase substantially, so a % per science is likely more suited, closer to set / forget.[/VOT]

--//--

Didn't know this project was having issues until I saw my stats showing low output, then read some of these posts. Removed one machine to HFCC. Hope it's back full throttle soon.

A very interesting conclusion can be made from the SekeRob's explanation (please correct me if I'm wrong):
If you are doing more for one specific project - that means somebody else (who selects all projects) is doing less for it and more for all the other projects. So no matter which project you select to crunch for - you are always crunching for all of them.
(There is only one exception - CEP2, because it's not automatically selected when you select all. So there are not enough people who have CEP2 selected and even highest feeder priority cannot help here.)

Out of this conclusion I would assume that the speed of a particular project (non-CEP2) is basically dependent on the whole WCG-speed and settings in the feeder made by techs. How many people are crunching the project exclusively - is not changing much as long as there are enough people who are crunching all projects.

In this case it always makes sence to crunch the project which better fits to your hardware (to make more work) and not the one which you give your preference to. Except CEP2 of course...

krakatuk

Yes - the 'Conscientious objector' idea - move those who object to one form of service into another.

It would seem that no matter how 'popular' any project may be, the unseen hands can tweak the uncommitted processing power to achieve whatever project balance they desire.

This defeats the entire concept of selecting projects to run - or to exclude.

You aren't the first person to come up with some inordinately long estimate based on a very small sample. Ignoring the inherent bias in making predictions on a small sample, simple logic dictates that an 18 year run time would be impossible. Look at how quickly computer hardware advances in one year and extrapolate the power of the grid out to 18 years from now. If you can't draw a reasonable conclusion of why your estimate is unreasonable, then it's beyond me to explain it.