Theres is a fundamental misunderstanding about the "Write to disk..." instruction. The setting works as a limitation, not as an instruction. This means that if it is set to default 60 seconds it works as an "at most" interval control (limit). The application itself is in case of CEP2 split in 16 jobs (really 1 setup and 15 segments). Each job can take from few minutes to multiple hours, depending on speed of device. Only at end of a job/segment does the science ask if it's allowed to do a WTD and the client will say yes, IF 60 seconds have passed since the last checkpoint save.

So, with CEP2 it is, that if you don't want to loose hours it's best to let it run to the end or look in the task properties when the last save was made **, then hibernate rather than power down.

Sorry, but that's how it is with this "opt-in" science.

--//--

** The Task properties note Elapsed time, CPU time and Last Checkpoint time. The differential from Checkpoint time to CPU time is the indicator if it's a good time to shut down or wait for the next checkpoint save, which is hard to decide if running a quad all mounted with CEP2.

edit: the spell-monster struck again.

Well, can't change it, lest you want these 1-2GB sized models to save every minute. Then picture what that would do to the usability of your computer while you need it. Of course WCG and CEP developers could not possibly allow that to happen, so this is as said opt-in plus a little hands on for those that do not crunch 24/7. Still, 23 thousand results validated yesterday. The tasks are currently working on lighter compound configurations, so on a Q6600 they take 2.25 hours for 16 checkpoint saves... grab them while they last.

--//--

Yes, Hibernation with LAIM on (specific CEP2 advise) gets very frequent mention on the forums, so it's hardly something brought up [sorry I did not]. Glad you discovered the way to go.

Happy Crunching.