This is a problem of workunits. They should all really have the same length.

gdf

It will take time before the enhanced routines in the faster apps can be incorporated into other research tasks; you can't change the routines mid-research as it would undermine the methodology. You can however, finish a research topic and move on with new improved applications and even use those to add validity to previous work. I'm sure that if improved routines can be applied to all the task types they will be, and this would bring some equality to tasks (in terms of time per step).

I guess the scientists would need to spend a lot of time making server side changes to facilitate this, but I do like the idea of choice and people being able to chose tasks that run on their systems and not tasks that do not, including myself; when my GTX470’s run KASHIF_HIVPR and IBUCH tasks there are no problems at 715MHz, but if I try to run a GIANNI_DHFR500 at that frequency it usually fails. I’m testing some settings and don’t want to change the 715MHz, but even if I was not if I reduced the cards to stock they would take 18% longer to run all tasks, while if I leave the cards at 715 the GIANNI_DHFR500 tasks would error out and I lose perhaps 18% runtime that way. Neither option is ideal. If I could just select GIANNI_DHFR500 I could leave the cards at stock, or if I could uncheck it I could leave them at 715MHz. In the past I also had cards that would only run some tasks; some always failed after a few seconds, and others usually failed after a random but substantial amount of time.

As well as the administrative overhead and unseen problems, one problem I can see is that people would only run the fastest tasks. If not facilitated correctly this could undermine the other research projects and we would soon run out of some task types. The option to crunch other tasks if no WU’s are available (or not for known cards that fail) would help defeat this problem and if enough people chose to run all tasks (the default setting) then they would just pick up slightly more tasks that others do not like to run. In theory this would on the whole speed up the projects and reduce server overhead (but practice and theory are not the same).

I also think reducing the return deadline to 3 or at most 4 days would help prevent task shortages; to the project a card that takes more than 2.5days to return a task is not worth much – by default boinc cache is 0.5days and tasks are reissued to fast cards that can usually run the task under 12h, so it will get returned inside 3days of the original task being sent, making it irrelevant. It would actually start running within 2.5days from the original task being sent, so after 2.5days (by Boinc default settings) it does not get recalled by the server, even if it does get completed by the first card. Basically, very slow cards just slow the project down as each new task is generated from the results of previous tasks. Seperate these batches out by project and we could frequently find oursleves waiting for 3days for the last task to be returned before the next batch is generated, unless projects were themselves seperated into different runs, which would mean a project rethink.

Until all the projects use the faster code, and perform equally (if this is even possible) there would be an inherent points attraction to faster projects, and nothing to offset this. My guess is that most people don’t know what projects there are, so they are not going to chose for any other reason, with the obvious exception of the HIV tasks. This is probably not a good thing.

Then there is the matter of all those crunchers choosing the wrong settings, and CA’s can’t change these (to do with Boinc not GPUGrid), so it would mean more work for the scientists and probably creating default setting parameters so that cards would not get tasks if they are known to fail those task types, until this is unchecked by the user (say after a driver update). But if the user did not do this they would just stop picking up tasks altogether, or until some default settings kicked in again.

We submit different Wus every week. As far as I understand other projects use different application names to let people select which WU to crunch, but in our case this would be impossible.

gdf