Have to agree with Movieman, I too have gone to 100% MCM, I did try and abort all Vina ones, but that was micro-manage too far!

Something I need to add so there aren't any misunderstandings: Point's per se aren't important to me and people that know me can verify that I've put my machines in others names to the tune of well over 10 million WCG points.
What does matter and to me is a big thing is fairness and equality.
I've seen small flocculation's between the projects over the years and never said a word but this is different and needs to be addressed.

There was a post that suggested to use app_config.xml to limit the running of faah to one with the <max_concurrent> tag so you could run all fahv and basically obstruct faah to just one core. You can do the reverse too, but given the weight in the feeder, that will be a lot of aborting on your 40 core device as you can't stop fahv from coming. I took the original advice and applied to a 4 core. It's running 21k points average on fahv with the occasional faah slipping through. The good excuse is, on linux these fahv run so much faster, it generates about 60% more work than on windows, really demonstrating how snail slow the autodock application is. Once a day I go in with boinctasks. The summary view reduces all ready to start on a per application basis to a single line. Select, delete key or right key and abort. The buffer is set to 1.2 days, so when deleting and new work arriving the faah are always the newest. Based on the fifo principle faah hardly get the chance, only fahv running, long as doing the daily visit.

Personally i think it presumptuous on part of wcg to not allow app level selection. Somewhere saw a post talking about code freeze, deep freeze it seems as this is now how long the situation being the excuse not to change this? In the newest beta uplinger was talking about flex, lengths of tasks. Maybe they've gotten closer to offering more regular runtime tasks matched to the power of a device. It will require a substantially different logic than the present 'stupid' project averaging method where any runtime outlier from present mean is being penalized, the 3 to 80 per hour variations you get to see. Since there are so many batches and experiments in circulations for fa@h, nothing consistent. This volunteer contributed chart shows the variations of recent. See how from smooth runtimes it's gone roller coaster from about the start of march? This is at project level, which hints at how much worse down at the individual device the situation is.

Ps, running dedicated per device, with an external project as zero weight backup. Only work is fetched there when the buffer is empty. Not the random backfill when one or the other wcg project feeder has a hiccup. Dedication has it's limits.

Oh, the indian with the pillow is still roaming the hallways but not allowed in, or out if you will.

I'll just throw my two cents worth in here. Movieman makes some good points. Since this is a volunteer effort, everyone is free to pick and chose the WU they run. Any results produced I'm sure are appreciated, whether it is 1, 10 or many more.
That being said, with the FAAH project there continues to be great disparity in how efficiently the units run. I believe Movieman runs his system on Windows, although he has dabbled with Linux a bit. From what he is saying, under his setup the autodock units run more efficiently than the Vina units. Under Linux, just the opposite is true, for the most part. Under Linux the autodock units run pretty steady at about 20 PPH plus or or minus a couple of points. The Vina units continue to be all over the map. Some as high as 80 PPH and some as low as under 10 PPH. I know just enough about programming to be dangerous but not proficient. I can understand why this point disparity is so, but that does not seem to make it "fair." But as long as the scientists are getting the results they need, I guess I am OK with that. This is complicated stuff and I am pretty sure when they code these programs they are more concerned with the validity of the results, rather than tweaking the code to run with greater efficiency on any particular hardware/software combination.
Really would be nice to have some consistency though.
Cheers