SLM is not an alternative client or plug-in. It's a stand alone program and it won't bother BOINCView at all.

That seems like an idea worth discussing if that's what you're saying.

Q6600 2.4ghz has 2x4mb L2
Xeon 3.6ghz has 1mb L2

The former does certain jobs at half the time of the latter, perceived powerhouse, so my next replacement coming up for the P4HT would be a QX9650 45nm with 12mb L2, just 1300 USD i read :( Might earn it back on the ebill though :)

even though, at times it would be quicker to go directly to the HDD.

two_agd_anthracine alone..................................................... = 2.15%/hour.
two_agd_anthracine with other project................................. = 2.15%/hour (very low cache demand, runs on 128K level 2 cache very well)
two_agd_anthracine with other QMC (last2_224_peptidexp) = 1.43%/hour (lower cache demand for peptidexp)
two_agd_anthracine with another two_agd_anthracine........= 1.03%/hour

As was shown a few days ago in a screenshot from Process Explorer (Post Nicolas), the elevation of BOINC.exe, though doing something to up the stability and increase of the test results, the actual individual test thread runs at low priority, which is why we barely notice it takes place. Would the test be elevated, a user will experience this while using the computer (you definitely notice it when the old WCG UD agent runs the test). Dilemma, should a user be submitted to that? Maybe if so, the pre-benchmark routine should sense if a system is idle for x-minutes before launching. Given it runs once every 5 days, that seems an viable fix.

I'm not sure if processes can change their own priority level on the fly but if they can then it should be easy to mod BOINC to raise it's priority just before it runs benchmarks and lower it after benchmarks finish. That might not be acceptable to some users so that feature should be made optional with the default set to off. There should be a warning if user turns the option on.

Rather than comparing credits between projects, you compare positions

While I am aware that some projects have fairly constant run times within a project others do not. At least with a firm base to build upon, the likelihood of an appropriate algorithm being developed to deal with this situation greatly increases.

you've gone from a system in which a fairly accurate/reliable extrapolation is envisioned to one where we measure the worst case scenario, whatever that is, and then let the chance that the WU takes less time determine the final outcome. I don't see much chance of a system that works on chance ever getting off the ground.

And since it's all happening on the host it will get cheated anyway.

They are not as easily cheated, they're easier to define, easier to code, easier to tweak too.