That I presume is part of plan to soon be able to size work in a fashion that all can run similar run times, not only on RICE, but also for the Autodock based projects. Was there not mention of dynamic sizing?

Don't think BOINC distribution system is able to save up many little tasks and than do a batch wide validation if that's what you meant. Sizing tasks down is not an option as it creates too much network load... the reason the jobs were sized up. The optimizing is in this device matching which will allow also to decide sending the heavier tasks of some sciences to the more powerful machines. There was talk some months ago to have a profile option such as heavy/light work plus some other bolts such as preferring longer or shorter. I forget the exact plan but it's kind of in the vein of getting closer to what can be done at Rosetta: Give me 2-4-6-12-24 hour jobs, not all sciences suitable to that approach.

Martin,

It would require substantial re-writing of BOINC to be able to do as you are saying (i.e. after the two results are returned, send out a third that only completes the work not done by the shorter). I agree that this would be the best - but it simply wasn't feasible.

Sekerob,

Both bits of logic will be useful. The framework to have different size workunits that are then targeted at computers that can process them in a reasonable amount of real-world time is in the latest version of the server code. We need to apply the latest updates to get it.

However, for some projects like HCMD2 our estimates of difficulty are so inaccurate that we cannot use that mechanism in quite the same way. We can instead simply says workunits A,B,C will be processed by 'powerful' computers, workunits D,E will be processed by 'average' computers, and workunit F will be processed by 'less powerful' computers.

We are likely to implement a mechanism to handle this second case sooner and then work with BOINC to implement several things that were discussed at the conference that will reduce the time it takes workunits (and batches) to complete. These changes benefit the members because credit will be awarded faster, it will benefit us because it will reduce rows on the result and workunits tables and reduce file system usage and it will benefit the researchers because it will get them their results a few days quicker.

Please excuse my lack of knowledge regarding HCMD2, but why is there a cut-off point for any system??

I'm sure there's a good reason for it, but without knowing why, as long as the result is returned within the 10 days', it seems strange to have the work unit cut off after 6/12 hours of crunching?

Hello themoonscrescent,
You have to think of people who are not keeping their system running 24 hours per day. Such people do not like having very long work units. Additionally, each turn off/on causes a restart at the last checkpoint which slows down again the computation of the work unit.
For all these good reasons, WCG designs the "parent / children / grandchildren" approach even if the related validation process is not particularly trivial.
Cheers,
Yves