CEP2 is more CPU intensive than the others, each wu takes it in turns to have CPU cycles, even on large well resources systems.

There are several things that can be done to assist

Ensure plenty of RAM in the system - CEP2 likes ram
run 1 less wu than CPU threads/cores
Reduce the number of CEP2 wu's running by reducing the number allowed within your profile on the WCG web site

These are likely not the only things that will help, but in my smaller machines I found it helped...

A small but significant correction - The number of CEP2 WUs in a profile only controls the number of tasks fetched/ available in your queue to be worked on. It's worth noting that any selection other than the default value of "1" avoids the possibility of "bandwidth" problems.

To restrict the number of CEP2 WUs which can run concurrently you need to create/amend the app_config file. (Found in C:\ProgramData\BOINC\projects\www.worldcommunitygrid.org\ in standard Windows installation).

<app_config>
<app>
<name>cep2</name>
<max_concurrent>xx </max_concurrent>
</app>
</app_config>

xx Insert number according to personal preference/experience. Trial and error may be necessary.

Having created/amended the app_config file don't for get to "Read local prefs file" in BOINC Mgr.

You must be running BOINC 7.0.65 or later.

@Mamajuanauk, @PMH_UK

You were correct, running BOINC from a Ramdrive made all the difference, the CPU Time now matches the Elapsed Time (as it should). The runtimes when running 4xCEP2 simultaneously were 18.00/18.00, 17.14/17.14, 18.00/18.00 and 15.12/15.12. If CEP2 were to allow longer than 18hrs of CPU time, it would allow some of the larger projects to complete, but I'm sure they have their reasons to cap the execution time.

It does make me a bit suspicious of the actual code...there is no reason that a 6GBps SSD should be IO Bound. Perhaps the program should cache the writes to memory and write them at checkpoint intervals, instead of performing constant read/writes to disk?

In any case, my scripts are as below: ***EDIT*** Forum format blocks are case sensitive (CODE vs code), but code blocks aren't colour coded or formatted so they appear as QUOTE***EDIT***

Setup the ramdrive & copy the ssd contents to the ramdrive. You need to run this as root/su/sudo


Change Directory to the Ramdrive (/home/jagaer/boincram) and run the boinc script


Then run the script to copy the ramdrive to ssd every 60 seconds. Any user input will stop the script and perform a final sync, so you need to stop BOINC/boinc_client before stopping the rsync script


I realize this isn't foolproof, but it works well enough for me.

After those WU were completed, the time showing in the stats (CPU Time vs Elapsed Time) matches, but does not match the Bonic_mgr elapsed time when the WU drops.

I will try a reboot to see if there is some issue with either the client or the mgr.

Not that it really matters, as the ramdrive solved the real issue, now it is simply curiousity why the mgr shows a mismatch, but WCG shows that elapsed time == cpu time.

If elapsed time is based off of the system clock, then there is an issue with the cpu time calculation, but I haven't used a stopwatch on a WU so cannot confirm.

If CPU time > Elapsed time, then something is wrong. I have never seen this on my computer, so I wonder if this can happen if you have to restart at a checkpoint. Does a checkpoint reset elapsed time but not necessarily CPU time?