That would have to be a major hmmm, the techs maybe in the know if an extra routine kicks in after an unload / resume. An alternate test in that would be to untick LAIM and suspend a running Beta, which would unload it, then resume it, and see if the checkpoint intervals then too quasi double.

Anyway, now I'm going to suspend the one beta I have and see if I can pump up the completion time.

7.10 beta21 BETA_avx101118-015_r9_1_wcgfahb00400000_0 07:39:05 (07:34:39) 99,04 36,367 13:35:14 03d,14:05:11 8/31/2015 7:24:26 AM [0] 00:00:19 Running 32.33 MB 57.39 MB

(First step done, suspend the task with LAIM off did unload it per the TM, then set LAIM again and forced a resume. The task reappeared in the TM. It was at 7:34 for 36% equal to 36 checkpoints)

Will get back when done, tomorrow, if I don't forget of course, but it would have to become visible in a few hours as then the time per percent would increase.

Reminds me, had one on Linux, the only one that was restarted. It went from a linear projection of 48+ hours, to run 55. Here's the break snip

[11:21:54] INFO: Checkpointed. Progress 81000 of 100000 steps complete CPU time 140431.097665 SecondsChkpntInterval
[11:50:51] INFO: Checkpointed. Progress 82000 of 100000 steps complete CPU time 142163.434065 1732.336400
[12:19:38] INFO: Checkpointed. Progress 83000 of 100000 steps complete CPU time 143890.449300 1727.015235
[12:48:07] INFO: Checkpointed. Progress 84000 of 100000 steps complete CPU time 145599.502948 1709.053648
[13:16:42] INFO: Checkpointed. Progress 85000 of 100000 steps complete CPU time 147314.599345 1715.096397
[13:50:19] INFO:Turning trickle messaging on.
[13:50:19] INFO:Turning intermediate uploads on.
%IMPACT-I: Softcore binding energy with umax = 1000.00000
%IMPACT-I: Using AGBNP2: Analytical Generalized Born Model + Analytic
Non-Polar Hydration Model
%IMPACT-I: Hybrid potential for binding with lambda = 0.85000
agbnpf_assign_parameters(): info: attempting to load from SQL tables.
[14:46:24] INFO: Checkpointed. Progress 86000 of 100000 steps complete CPU time 150648.582080 3333.982735
[15:43:44] INFO: Checkpointed. Progress 87000 of 100000 steps complete CPU time 154068.058018 3419.475938
[16:40:44] INFO: Checkpointed. Progress 88000 of 100000 steps complete CPU time 157468.356532 3400.298514
[17:38:05] INFO: Checkpointed. Progress 89000 of 100000 steps complete CPU time 160892.862115 3424.505583
[18:35:14] INFO: Sending trickle message to server.

@Techs, concur with the previous observed: Toronto, we could have a problem! Seconds per checkpoint practically double after a break.

Never seen an answer to this either: If the generation 1 task is assigned to Linux, will all the following in the chain also get assigned to the same platform? Again, and opposed runtime doubling after restart, not the volunteers problem, just filling in the knowledge gaps.

We are looking into the issue of CPU time doubling after a restart, thanks to the beta testers for catching this.

Also the continuation of the simulation on second, third, fourth, etc. generation are not bound to the same platform, they can run anywhere.

Thanks,
armstrdj

I agree with Rarusu's comment about resent WU deadlines, although I suspect that the short deadlines of the beta test might be contributing.

However, if a WU is server aborted as out of time, surely the "resend" should have had a new number as it should have started from the last successful trickle result (assuming that there was one). It might help if you could post the log from your run -- were there any trickle messages?

Or maybe this isn't all sorted out yet ... ?

Thanks for the clarification.
I didn't catch that many beta WUs in the past and wasn't aware that this is a known problem in the field of the beta test.

As soon as I'm home I can look for a log and post the content. But the trickle messages shouldn't be the problem as I could observe a growth of elapsed time for the WU. In my understanding this can only mean that the trickle messages were received and validated by the server.