If we may call you Al, the impact of just 1 concurrent with 2.5 DSFL and .5 CEP2 that was running during the first part, the efficiency per BOINCTasks is 98.2% after 2:10 hours and 89 Checkpoints opposed to the 99.1-99.3% which is consistently recorded for DSFL (Linux). I'd be happy to test 4 concurrent, presently I've pushed a second ahead to see if there is cross impact.

-- Rob

Edit: I've long experimented with drive mount settings and found that *relatime* (now default in Ubuntu) and *noatime* (no read access updating, but write updating of timestamp) makes but a imperceptible difference. Will update when data becomes meaningful for different combos.

>once per minute, per task, might impact on lifespan of Solid state drives.

I'm running 3 climate models on an i7-2600 (8GB, using second HDD with Boinc, and only using 90% CPU), 2 HFCC tasks and one GFAM task.
The GFAM task has run for 60min, but is only at 5.5% complete. CPU time vs elapsed time is only 9seconds apart. The estimated time to complete is continuously rising. Is the progress way out, or is something else up? GFAM_x1df7_TBdhfrDry_0000245_0112_1

-- Was just the progress; it's now jumped to 25% complete, after 88min, and time remaining is 3h55min.
-- Now seems to be progressing normally; 37% after 103min, 3h remaining.
-- 75% took 3h 55min, 1h 18min remaining.
-- took 5.62h to complete, time lost was about 6min, ~1%

Jobs inside a task are variable and now having seen half a dozen, observe that efficiency rapidly increases with the time it takes to get to the next checkpoint... and the slower the HD subsystem, the more impact it has. Now one GFAM averages 1.5 minutes per checkpoint and efficiency perked up to 98.6%. That's with 3 DSFL on the side... running at that 99.1-99.3%.

Ignorant of what these science apps do, BOINC wrapper has a standard call function that can be activated. It is to let it ask the core client if it is allowed to write a checkpoint at what frequency. It only asks this once at start or restart of a task. Then it maintains a counter and if 5 minutes is specified, it will skip writing a checkpoint if the last one was nearer than 5 minutes ago. It resets at that point, so if it took 15 minutes for the last one, the next will again check if the 5 minutes have passed.

If CEP2 were to listen to this function, which it does not either, I'd be setting my WtD to e.g. 200 minutes on my 24/7 Linux box [on UPS]. I'm sure it would gain many minutes per task **. My boots and updates are planned, so I can switch to short checkpointing sciences if need be. Last boot per byobu was 11 days ago.

--//--

** Of course, the scientists may want to see the checkpoints in the result plot the progression curve, but I've never read that to be the case. No checkpointing at all setting 720 minutes would be foolish for this science, lest the state *as-is* is captured when cut off at 12:00 hours. Somehow doubt that happens. Would turn into a gigabyte upload :O| Anyway, just a sidebar, my main concern the staccato if 4 GFAM or more were allowed to run concurrently. The noted SSD's might not take that kindly either.

Double posting this comment:

Never seemed to worry me for DSFL at 99.2% efficiency, but if the 99.2% can be increased to 99.6% by the [though it could be arduous] -mere- change of the WtD setting compliance (C4CW+HCC1 do 99.8% on this rig), that'd be icing on the cake. Any company would love to see their profitability go up by 40 basis points. At any rate, if GFAM does 98.2 and DSFL does 99.2, that's potentially 1 percent to gain, if not 1.5% with the cases on DSFL observed by andzgrid. That's hundreds of CPU years on the project duration.

--//--