My thought as well. My contribution to CEP2 is my lowest of all the sub-projects for exactly that reason. The long run times and length between checkpoints pose a very real problem for me, so I contribute very little time to that sub-project.

Since this is Autodock Vina the way work *per-compound* is cut [seen ZINC named in the beta tasks], will be much identical to e.g. HFCC and FAAH. Don't think it will involve hard cut-offs at 6 or 12 or whatever hours in a complicated HCMD2 scheme.

Re checkpoints, 10x 2 to 2.5 minutes makes them to run 20-25 per checkpoint on me Linux 64 bit quad [32 bit app I saw in this test]. Not attractive for booting, let alone on me duo when they, based on ampc test observations, would be an hour apart. Pretty plz, 2-4-8-12 threaded devices will loose lots of progress on system or client restarts. Electricity being more and more expensive, it would not be a very green decision on top in this day and age to have long checkpoints and still seeking unhindered participation by all. Possible there is misunderstanding though what 10x longer checkpointing means, so lets hear the techs on that, what their plan is.

--//--

Those Betas I reported yesterday are still sucking wind.



Should I abort them or let them run?

It's inevitable that WCG will not be able to run all projects on all systems, so trying to fit square pegs into round holes is counterproductive.
The fastest CPU's can do 40times the work of the least productive CPUs. You simply facilitate the running of every project on every system. Project requirements are naturally different. So it's unreasonable to expect RAM usage to always be low, bandwidth to be low and run time to be even, and ditto for checkpointing. Just have a look at the trouble other projects have. If LAIM is presently fine for CEP2 why not this one? I don't like losing run time (during restarts) just as much as anyone else, but if this does not suite some people WCG has other good projects to choose from. Crunchers strive to be more productive, so if you have to modify things to the point where increased checkpointing slows the research down, you are losing as much as you gain, at best. Perhaps you will be able to find a work around, rather than universally chopping into everybody's run time to do checkpoints.

Could it be possible to add a feature where the cruncher could select to suspend the task at the next checkpoint? That way you could click the option, and allow the system to run to the last task checkpoints, and run other tasks as the cores free up. Come back in 20min and do the restart then. Perhaps even a checkpoint and then restart/shutdown the system function. Alternatively could you force a checkpoint only if Boinc is closing. That would deal with restarts, log offs and shutdowns and LAIM would deal with system in use task suspensions.
Could one of these task not be divided and allowed to run on each core/thread? I'm not suggesting this would deal with checkpointing, just asking.

?. We're trying to establish what these BETA jobs do and don't in the here and now, what they withstand and what-not, in amongst what happens if the client / system is restarted to see if it survives [an old trick on frozen jobs]. Beta testing is not lossless.

Suggesting this or that change to the client really belongs over at the Developers Alpha mail list or in Trac. You're a member of former.

--//--