After forcing one beta to run, after 1 hour elapsed and 57 cpu minutes, 5 checkpoints were logged. Not meat, not fish, no every second minute, not soon after the write to disc setting of 300 seconds, but probably after completion of each packed job in a task. The task indicates 3.571 percent progress, suggesting this is going to be running around 29 hours, if progress indicator is correct.

7.32 beta18 BETA_FAHV_x2BBB-AS_0879646_0076_0 01:00:00 (00:56:27) 94.08 3.571 04:00:16 03d.22:29:05 9/10/2014 5:47:42 PM [5] 00:02:41 Suspended: User request 0.00 MB 0.00 MB

How many jobs are packed in these tasks? Just to get a fair approximate duration. If it is same as production of 140, runtime might be 1680 minutes or 28 hours, meaning the progress indicator is close enough.

What i'd reported before was that these tasks under version 7.16 would easily log 350 checkpoints in a run, though there are only 140 jobs in a task. That was by design i think, to lose as little as possible on restart, downside of course the very frequent writing to storage, flash memory?

Now it appears the frequent checkpointing was removed, and just every job one checkpoint. At any rate, a second task checkpointed more frequent than the 5 minute settings, so that confirmed the write to disc was not being regarded.

Did not manage to pull some of those beta19/ugm1 beta tasks onto the android, so presume they're not aimed at this platform. Will they be in the future?

I've got two running on an HTC One running KitKat and they seem to be fine. I did lots of pausing, much of it from telling it to run on battery since the beta deadlines are short. The total runtime seems to be shorter than the current production ones. If the progress indicator is to be trusted both of these should be around 20 hours, better than the 25-35ish I've been getting, but then again that might just be random chance on the these two.

Glad to hear the new project is designed in a way it might work on mobile, but it seems like you guys have your hands full over there right now. Good luck


yaren

It's confirmed, 140 checkpoints, not that it was doubted. Progress closely tracks the number recorded divided by the number of jobs packaged. One is after 13+ hours at 65.7 percent per the agent with 92 checkpoints. 92 / 140 is, yes 65.7%.

Of interest is the efficiency, cpu time divided by elapsed. The detail tally i'm keeping gives on 165 results 95.4 percent. The first beta completed with 98.35 and the 3 running do so far 98.6. Is this just the effect of less checkpointing? Before no matter what, about every 1.75-2.00 minutes. All the more reason to make the app follow the 'write at most' if the very frequent checkpoint ability were to be restored. With the first finished in 7.25 hours it meant one write every 3.17 minutes, seeing in this no reason to program one to be taken more often, and introduce a source of wear and slowing and task problems. If it helps too to end the never ending barrage of '195' errors, a have to. The said 165 completed have a distribution average of 6.8 copies. Stable devices can do it alone, have logged 6 of those, not a single 195 fail. If the frequent forced checkpointing is part of the problem, leave it out. We don't need over 80 percent fail and personally, have no need to see 8 percent be taken out into 'too late' because there's no wingman to be found that can do the calculations correctly.