Thanks for the heads-up Uplinger

nanoprobe, I'm glad you mentioned the weird suspend behaviour, because I thought I was going mad. I suspended Beta tasks on one machine with LAIM off, resumed them, then checked stderr - but there was no indication of a restart. The CPU Time and Progress figures in BOINC Manager seemed to continue from where they were before the suspend. This was before the tasks had checkpointed at all. In my case, all 4 cores of the quad were running Beta tasks at the time, but with UGM tasks waiting to run. Here's a Result Log (my Suspend was at 22:19 GMT) - no sign of a restart; this task is now Pending Validation:

Result Name: BETA_ OET1_ 0000309_ xMBGP-OM_ rig_ 0519_ 0--
<core_client_version>7.2.47</core_client_version>
<![CDATA[
<stderr_txt>
INFO: No state to restore. Start from the beginning.
[22:09:29] Number of tasks = 1
[22:09:29] Running task 0,CPU time at start of task 0 was 0.000000
[22:09:29] ./ZINC01671640.pdbqt size = 20 1 ../../projects/www.worldcommunitygrid.org/beta20.xMBGP-OM_rig.pdbqt size = 1930 0
[05:11:09] Finished task #0 cpu time used 24020.191575
05:11:10 (17420): called boinc_finish

</stderr_txt>

PS Another Beta task is still running after 10 hours CPU Time, 90% Progress, last checkpoint at 8h 52m.

I got a number of these betas yesterday (8 Jan)(299 and 308 series) and today (9 Jan)(309 series), for Linux-x64 only.
(BTW, the Linux x64 beta program is 64-bit).
All tasks had "_rig_" in their names.
I couldn't seem to bust any by checkpointing them.
However, my i7-970 got 1 invalid result, and this machine hasn't had one of those for several years if ever: BETA_ OET1_ 0000308_ xMBGP-F_ rig_ 1656_ 1-- . The result log shows 3 starts (2 suspends?) and no error messages.

Today's tasks (309s) are running much longer than yesterday's 299s and 308s, by a factor of about 5.
Both series seem to checkpoint about 10 times during their runs.
Thus the shorter tasks checkpointed acceptably often, but the 309s often run over 2 hrs between checkpoints on the 970. I am monitoring the tasks using BoincTasks 1.66 , which shows time since last checkpoint in the Checkpoint column of its Tasks tab - a handy feature - and have seen up to 2h30m and counting there. I think that's longer than is desirable.
I know that one could get more accurate info on checkpoint frequency by setting the checkpoint_debug flag and trawling through the messages files, but I haven't got time.
OTOH, I would expect that the timestamps on the .ckp files in the slot directories would reflect the checkpoint times, but under Linux at least, all files have identical timestamps.
Why is this so?

My "farm" consists of the abovementioned 970 plus several 2600Ks and 3770Ks. On tasks other than these betas, the 970 (thirsty slug) takes about 40% longer than the LGA1155 machines at similar clock speeds. With these betas, it seems to take about 100% longer. Is there a simple explanation for this, eg different compiler or compiler flags used, more extensive use of CPU SIMD instructions, eg AVX?

The 309 betas on the 970 are still running, showing 20% complete after 9-10 hours. Are they likely to bump into an upper limit on CPU time?
---
BTW, another handy feature of BoincTasks is that one can set a "Suspend at checkpoint" condition on a task. (Right-click the task's entry in the Tasks tab). It's been useful in the current exercise, and would be useful when running any projects with long checkpoint intervals, eg when one wants to shut down a machine without losing crunching time. If the flag is set there will be an '=' next to the task's Checkpoint column entry. It does exhibit some quirky behavour though. Using it may consume considerable computing resources since it appears to function by polling, and this may be the reason such a feature has not been implemented for BOINC Manager.

I didn't stay up last night to babysit this latest 309 batch, and I'm glad I didn't!

On my lappie the first checkpoint this time was after 4.5 hours. On my ancient deskside it was after 10 hours. Only one has finished and it's still PV. All the ones from the previous 299 batch are now validated, and I had restarted all of those after the first checkpoint.

I've found that, although the checkpoint files in the slot directory all have the time of the latest write, those in the enclosed vina_checkpoint directory have what appears to be the time of the actual checkpoint.

Subsequent checkpoints seem to come more quickly (around 2 hours on my lappie for batch 309), but are still what I consider to be a long way apart for my rather "ordinary" machines. I would argue that a project where any of the checkpoints are likely to be more than 3 hours apart on a typical volunteer's box should be opt-in only, but that's just my view. It is based on the point I already made about machines being switched on and switched off again before a checkpoint has occurred.

Hmm, weird display in BM now: Both units were back to 10% although they are running for more than 6 hours and showing an estimatet time to go of about 1 hour and 38 minutes?

[WORK UNIT, RUNTIME, PROGRESS, CHECKPOINT]

BETA_OET1_0000309_xMBGP-OM_rig_0463_0, 06:18:00, 20%, yes, estimated time to go (01:00:40)
BETA_OET1_0000309_xMBGP-OM_rig_1242_1, 07:13:00, 10%, yes, estimated time to go (00:39:01)

Edit:

BETA_OET1_0000309_xMBGP-OM_rig_0463_0, 08:25:00, 100%, yes, uploaded to host
BETA_OET1_0000309_xMBGP-OM_rig_1242_1, 12:20:00, 40%, yes, estimated time to go (02:57:41 and rising)

Edit: Both units finished, but only 1242 (runtime nearly 19 hours) was valid. 0463 took more than 8 hours and was invalid.

System: Quad Core, no HT, Windows 7-64, BOINC 7.2.47