BOINC - CPU Time vs Elapsed Time

Brainbug

Weaksauce
Joined
Feb 15, 2012
Messages
92
The CPU Time reported by BOINC Mgr is not the same as the Elapsed Time.

I am curious if anyone else is experiencing the same thing, or understands the cause. The only thing I can think of is that the CPU Time is based off of the benchmark values for a single core, where the Elapsed Time is the actual processing time of the WU. This wouldn't be an issue, except some projects stop after a certain number of CPU Time Hours.

Examples:
CPUTimeElapsedTime.png
CPUTimeElapsedTime2.png


Running 31 threads on 32 cores from a ramdrive (ramdrive syncs to ssd every 60 seconds)
 
What you are experiencing is odd. I am wondering if you had rebooted since the last check point or had shut down BOINC manager and reopened it. The Elapsed Time should always technically be greater than CPU time because CPU time is how much time the CPU has given to the work units and Elapsed time factors the Work Units and all other processes using the CPU (such as the OS)
 
For example, CEP2 does a ton of disk IO's. The time spent doing those don't get added to CPU time because it doesn't crunch during those. However, Elapsed time should continue to tick away...
 
The good news is that credit is typically calculated based on CPU time. Or at least that was the last I had heard. This issue does happen from time to time and there was a post over in Cosmology (though it should have been at Einstein) back in 2010 with someone mentioning the same issue.

http://www.cosmologyathome.org/forum_thread.php?id=757#8826

The times that CPU time isn't used and Elapsed time is also depends on which credit system they go with. If Credit New is used, (SETI) then I think Elapsed time gets factored. I know many projects stopped using Credit New when they realized how terrible it was. I think WCG uses a modified form of it.
 
Last edited:
But to be more clear, run time for GPU's typically use Elapsed time since they use very little CPU time and the credit system was based on CPU initially.
 
What you are experiencing is odd. I am wondering if you had rebooted since the last check point or had shut down BOINC manager and reopened it. The Elapsed Time should always technically be greater than CPU time because CPU time is how much time the CPU has given to the work units and Elapsed time factors the Work Units and all other processes using the CPU (such as the OS)

Thanks for the quick reply.

boing & boincmgr haven't been restarted in the past 4 days and both WU pictured above were downloaded and started without interruption.

I am under the same understanding as yourself, that CPU time should always be LESS than elapsed time. I can only assume that it is either using more than one core, the CPU Time is based off of benchmark time or it is referencing the stock freq not overclocked freq (note turbo is disabled on this system, it is permanently running at 3.9 on all cores at all times)
 
Last edited:
Then I would suggest restarting and see if this clears up. Or wait for these work units to finish and see if it continues. Elapsed time should always be greater. On a Credit New project, you would be losing points because of it.

Elapsed time takes into account the additional overhead a work unit may have outside of the CPU as mentioned above with CEP2. Systems using Elapsed time are taking those additional over heads into account. Otherwise, those apps penalize you to run because they are "wasting" time that could be generating points.
 
For example, CEP2 does a ton of disk IO's. The time spent doing those don't get added to CPU time because it doesn't crunch during those. However, Elapsed time should continue to tick away...

Running 4xInstances of CEP2 was maxing out a 6GBps SSD on a SAS2 connection...there is something wrong with that program at the design level (should be writing to memory and flushing to disk every checkpoint or xx seconds, vs the constant IO)

Running CEP2 from a ramdisk avoids being IO bound, but shouldn't be necessary...
 
That has been a discussion at WCG since it started. They have made some improvements, but the scientists claim nothing else can be done at this time. Ram Disk is the best option for eliminating that headache or if you don't mind the risk, you could set your checkpoint at most time frame much higher. But I don't think it is the checkpointing causing the IO's issue.

CEP2 is a project that I think really needs to find a way to run on GPU.
 
Then I would suggest restarting and see if this clears up. Or wait for these work units to finish and see if it continues. Elapsed time should always be greater. On a Credit New project, you would be losing points because of it.

Elapsed time takes into account the additional overhead a work unit may have outside of the CPU as mentioned above with CEP2. Systems using Elapsed time are taking those additional over heads into account. Otherwise, those apps penalize you to run because they are "wasting" time that could be generating points.

I'll try waiting, but am not hopeful, failing that a reboot.

I just think that BOINC/WCG wasn't meant for the types of systems currently being used.

Maybe Tear's new NUMA-Aware client will help (haven't tried it, since I'm running 7.2.0 currently and haven't had the time to diff the 7.0 version its based off of and implement the changes)

The client I'm using is custom-compiled for my system with gcc using bdver1 and O2 optimizations

On the upside I did get Ruby on MCM and Gold on FightAids after only 6xDays of crunching :)
 
I also don't run more than one CEP2 unit at a time on my systems. Though I have ran up to 8 on a traditional hard drive, I didn't look to see if there was a loss in production. Some hard drives can't handle one CEP2 work unit. (cough...shit Hitachi's...cough)
 
Yeah...try Tear's some time and give feedback on it. I think it is great that our team is doing more with BOINC now. I have little experience with Linux, so shamefully, move slowly towards that realm. My Linux offerings are usually a VM here and there.
 
Back
Top