Just to clarify this a little bit: CPU time is always less than WC time, because not all work done by your computer is CPU based. I/O is a prominent reason - but obviously a necessary evil (after all we have to save the data of a calc to do something with it in the end). Other use of the CPU (e.g., by the OS or other software) also adds to the discrepancy between CPU/WC time. If there are a number of simultaneous wus which all try to perform I/O, they have to basically wait for each other. In this case, the CPU time stands still while WC time moves on, which leads to bigger discrepancies. The more wus run simultaneously, the higher the probability that there will develop some I/O holdup.
Best wishes
Your Harvard CEP team

Got it running in ''virtual'' SSD on Linux using the zramswap-enabler. This way it only goes to HD when checkpointing. Whilst, the amazing thing continues to be that when running CEP2 (and DSFL, both using a staging wrapper construct), run 99% efficient with a regular HD on Windows, booting same device to Linux, I'm barely getting 95% [and only when really hands-off] and only if not running more than 2 concurrent on a 4 core system. DSFL then has a hard time getting 98%, not 99.5% seen under W7. The Linux setup is truly bare, no GUI. I've actually launched a query over at the Ubuntu support forum to ask about fstab parms that could optimize. noatime, relatime, write-back delay etc. Nothing seems to be making a dent in the poor efficiency, to repeat, only under Linux with the 3.0.1 kernel.

--//--

Thanks for the replies. If I wasnt so close to getting sapphire, would try a second hard drive for boinc only. This way, both spin up for their own reason, instead of sharing the disk. I increased my write times to 120 seconds yesterday to see what happens. Same or worst. I have an older 30gb ssd drive I will try later just to see what happens. It was cheap so if it dies, no big deal.
One thing I do though is leave one thread free for other processes needed. Am hoping doing this wont interfere with boinc.

Dear warmachine,
yes, multiple harddrives are successfully used to eliviate I/O bottlenecks. We recently extended our inhouse cluster with nodes set up this way. But we certainly cannot ask WCG users to buy additional hardware just to maximize the CEP2 return.
Best wishes
Your Harvard CEP team

@cleanenergy
It seems you missed (or ignored) my post on Oct 25, 2011 8:48:08 AM where I finished with the following:
Tonight I have been happy enough to be able to watch the end of job #2 of the CEP2 WU which is currently running in my quad. I watched it via BoincTasks running in my netbook, so I did not interfere with the quad myself and CPU efficiency was about 99 % on all four tasks (3 HCC WUs running along). Here is what I could see before and after the checkpoint between job #2 and job #3:
Before:
Difference between wallclock and CPU times: 0:03:35
Last CPU time shown by BoincTasks: 3:29:17
Just after:
Difference between wallclock and CPU times: 0:15:00
CPU time shown by BoincTasks: 3:18:00

My BoincTasks is refreshing every 15 seconds, so all these changes happened during an interval of 15 seconds.

Of course, at the same time BoincTasks started to show a blank field for CPU efficiency until the CPU times become consistent again over its computation interval.

I think that this is confirming what I said earlier: chasing I/O overhead to get rid of the big differences between wallclock and CPU times for this project is not the point (although it cannot hurt ). The problem is something wrong in the master procedure which manages the 16 jobs of a CEP2 WU.
But what ?