The present HIV task failures (on some CC1.1 cards) have once again highlighted the limited control crunchers have over the tasks they/we can choose to run.
Perhaps it’s time to rethink the situation; to enable crunchers to run specific tasks, or more importantly choose not to crunch tasks that continuously fail.
For most selecting to run All tasks will still be the choice and default setting.
This could always be reset following new app releases, should the scientists decide.

I would like to be able to direct someone to stop crunching a task if that task type has become a continuous failure on their card. I know in the past that some of my cards on certain operating systems did not behave the same way as on other operating systems, but it is too much to ask a cruncher to change operating systems because a few tasks fail, and when they are using the most recommended operating system, there is nothing else I can do for them.

If that cannot be done, perhaps the servers could keep a failure record and only allocate tasks that are known to work on that card/system.

For example,
If KASHIF_HIVPR_n1_bound_ tasks continuously fail, on someone's CC1.1 card, the server could just send other tasks to that system.

Two other suggestions,
A check box for the Green (noob)/ or just busy user, so a CA/technician can configure their settings (would only become applicable if the first suggestion, above, was implemented).
Have the PM’s go to email by default (so crunchers have to opt out if they don’t want messages to go to their email). That way we can tell the Fermi users, the ones that don’t check the site or their PM’s, that they should upgrade their driver, unless they really want to only crunch 6.06 tasks (over 10 last time I looked, and at least one had two GTX480’s). Better than an unread message in Boinc.

For us that would be fine, but this is a BOINC wish...

gdf

Other Boinc projects such as ClimatePrediction, ibercivis, yoyo, and WCG group tasks into sub-projects, so users can opt into some or all. This is done on the project web server, but these are largely considered all-one-project by the Boinc client. There are many benefits to this; for example users can run tasks that require less bandwidth, time to complete, system resources, or just the tasks they are interested in.

I'm not aware of all the constraints that come with using Boinc, especially server side, but from what you say I guess the situation differs for GPU projects.

Thanks,

How do you select the sub-project to participate to there?
The only way I can think of server side is to create a different application which is identical but with a different name.

gdf

Yes, this is how they do it. Different applications are different projects.
In their case, it is really a different application so it is quite easy.

In our case, maybe we can split workunits into long and short and assign them to different applications. This would be easy enough.

gdf

Yes, different applications are used for different project by other Boinc groups.
Although you could separate according to project, HIV for example, you could also separate according to task size.
By project would mean that users could de-select a project that regularly fails.
By size would allow people with slower cards to just run shorter tasks.
Both separation methods would be useful, so perhaps both are feasible?

On the face of it this still sounds like a good idea, but I don't think it will be implemented:
The researchers are presently busy preparing publications. There is a planed move to new server software, and following that some site changes. An ATI/AMD Alpha project might start up soon. The other thing is the intended move to CC1.3 or above cards only. That would mean my GT240 (CC1.2) is no longer useful. Similarly your 9800GTX and 8800GT cards (CC1.1) would become incompatible. If and when this is implemented it might make project selection largely unnecessary, at least for the purpose of selecting/cherry picking tasks that run well on your system; the CC1.3 cards and Fermi cards are less likely to fail one type of task.