What you are dealing with here is part of how BOINC processes work. It's called checkpointing. Basically, BOINC writes to disk data about where it's at processing a workunit. If you stop BOINC running, when you start it up again, it uses the last data it saved about that workunit to start back up at that point. How frequently BOINC checkpoints on a workunit depends on the science application for that work. Typically, you'll see workunits for most projects checkpointing frequently so very little work is "lost" when BOINC has to restart working on a workunit at it's last checkpoint. CEP2, which is what I think you are referring to, is not one of the typical projects. Part of its nature is that it is not able to checkpoint very often. It can also be memory intensive. If you select a WU on the tasks tab in BOINCManager and click on the Properties button, you'll see information about that WU. The difference between the CPU time and CPU time at last checkpoint will give you an idea of about how frequently WUs for a project checkpoint. WCG runs projects at times that are worthwhile but that have characteristics that can make them unusual such as having high memory requirements or being unable to frequently checkpoint. Yes, this can be frustrating when you're unaware of this but it does not diminish the value of the project. To run CEP2, you want to make sure you have enough memory for the number of workunits you run at the same time. You probably will also want to set "Leave applications in memory while suspended?" to Yes in your device profile. There's also a project specific section for CEP2 that you may want to look at as well.

EDIT: Also, CEP2 is a project that is better suited for machines that are left running 24x7. If you don't, you'll want to check how long it's been since the last checkpoint to decide if you're willing to lose that much work before you shut down.

Hello P.Henry.ForbiddenCity and welcome to WCG.

In a way, demands from people are healthy if only to the extent that these demands play out to make grids not pause in their search to improve any aspect of grid operations vis-a-vis improving the cruncher experience.

On the other hand, but precisely on the vein of wanting to improve things, some 'out-of-the-typical' or 'odd-ball' situations are explored. The CEP2 project, in my book, is a good candidate for that situation. Conceivably, there may be something to learn from doing those 'odd-ball' things -- arguably for both the grid and the cruncher -- an opportunity that will not be available if all we do are 'typical' or 'standard' things.

If you don't care much for such things, there are many other projects here at WCG that have proven to be machine-friendly. Oh yes, there are hiccups here and there, which is no different from the other things we engage with in the real-world.

Please do not throw in the towel easily and remember, the greater the adversity, the sweeter the victory! You did set out to win, didn't you?
;