FWIW I have tasks on 1 machine that run in excess of 15 hours. The longest running task from the previous 2 beta runs was 3 3/4 hours on said machine. Just curious as to what the techs are looking for with 4x longer running tasks.

Probably answered briefly in this post earlier in the thread.

Also with batch 309, 6 WUs running but not checkpointing after 4 hours. Changing LAIM setting rewrites the init_data.xml file but nothing else is going on in the slots directories since the WUs started. I guess with multiple folds in protein targets we will see huge variability in the completion times which will most likely mask the CPU times lost with suspend/resume with LAIM off. I was expecting that the suspend/resume actions would result in something appearing at least in the logs in the slots directories, but there is nothing. I would expect beta WUs to produce more verbose logs to explain what's actually happening (or not).

As for the progress and remaining time estimates: After starting, the percentages for the WUs progressed rapidly consistent with the initial estimate of remaining time but by >80% the linkage broke and the remaining time was in some cases "---", Eventually they dropped back to 10% one by one and remaining times are either static or increasing, and contradictory in the context of the elapsed time and progress ie. if 10% after 4H00 then the remaining 90% won't be 0H22!

A 10% WU that I suspended and resumed without a checkpoint has presumably restarted from the beginning but the progress and remaining time did not revert to their initial behaviour. I'm expecting it to be the last one to get to 20% as it has already slipped to last position amongst those still on 10%. We shall see.

Edit: Checkpointing started at 3H47 for the WU at 30%, 4H09, 4H54, 5H06 for WUs at 20%, the other 2 WU have not checkpointed yet at >=5H30. The WU suspended/resumed with LAIM off is not the last to get to 20% either, so overall a great deal of variation. Anecdotally, the first WUs which checkpointed are the only ones where the other copy in the quorum already has the result returned, so the first checkpoint time might prove to be proportional to the duration of the WU.

I catch my first 4 beta today.

I'm running 3 CEP2 and one beta (batch 310), turned LAIM off. Then I stopped the beta task two minutes after start. Boinc manager showed me, the first beta stopped and the second beta started. Looking at task manager, I see there are running 5 tasks, 3 CEP2 and two betas, all abot 20%! Normally I cannot run more then 4 CPUs at the same time.

I have no possibility to stop a started beta task. So I waited to next checkpoint of CEP2 and stopped it. Then there are now running 2 CEP2 and two betas.

Can I let 5 tasks run parallel or may this be a problem?

edit:
task1: BETA_ OET1_ 0000310_ xSDGP-F_ rig_ 0614_ 0--
task2: BETA_ OET1_ 0000310_ xSDGP-F_ rig_ 0601_ 0--

I've picked 31 beta units last night, 309 type, in a dual sandy brdige xeon at 3 GHz (hypethreading ON), linux 64, Boinc 7.0.65.

First batch of 10 units executed without interruption between 5:50 and 8:20 hours. Most of them already validated, some waiting the wingmen to finalise, no invalid one so far.

With the remaining 21 units I've been playing with suspending and resuming both without closing and closing the boincmanager, which has the same effect wrt resuming. Checkpoints were taken between 1:30 and 1:50 for the first ones and around 40 to 60 minutes for the following ones.

Progress percentage advance in jumps of 10%'s (not related to checkpoint made). Times to completion are certainly off of the actual values.

If a task is supended and resumed, the elapsed time goes right back to the last check point time. However, the progress bar percentage takes some minutes to go back and in several cases, not sure if in all of them, it goes back much beyond than it would correspond,for example to 10% when it was at 80% before suspending. It does not seem to affect to wu completion time.

I've noticed that when a task resumes the date of all the checkpoint files, even the ones from previous checkpoints, is updated to the date of the resuming moment, not to the date when the checkpoint was performed.