Hi,

You can put your log file into for instance dropbox or some other hoster and post the link here.

Yes, if you run 24 simultaneous I'd expect things to start *crunchy*. It's with CEP2 good practice to slow build the number and let the other cores do the lighter stuff such as HCC or HCMD2.

There's no way to see the Elapsed/CPU time differential after upload. Many use the BOINCTasks tool that can simultaneous track hundreds of clients on a LAN and runs on Windows natively or in a VM/Wine on Mac and Linux. That logs all results and gives both times.

--//--

i don't know if my link works but here is an example



and i found the following

http://setiathome.berkeley.edu/forum_thread.php?id=65060

i have Origin running. I shut it down and i started again all cores... let's monitor.


Edit: It did not help. i still facethe issue i have reduced the number of cores to 16

You can use job_log_project.url.txt for this...

This is easily done with example Excel, the biggest problem is that many of WCG's sub-projects hasn't human-readable task-names and I've got better things to do than remembering that the various cryptic letters V*, os*, q?*, M* and C* stands for.

For the sub-projects that does have understandable names, or I'm remembering X is HCC and E is CEP2, it was easy for me to calculate info like this, for data on the computer mostly crunching 24/7, used only data since 01.08.2011:

HCC: min efficiency, 94.85%, max efficiency, 100.09%, average 99.89%, std.dev. 0.315, 28 of 2228 tasks has more than 100% efficiency; min: 1.22 hours cpu-time, max: 1.58 hours, average: 1.39 hours, st.dev 0.089 hours.

GFAM: 98.99%, 99.90%, 99.69% average, 0.189 st.dev, 49 tasks; min 2.52 h, 8.64 h, 5.44h average, 1.15 h.
C4CW: 97.36%, 99.83%, 99.55% average, 0.292, 753 tasks; 3.19 h, 3.27 h, 3.22 h average, 0.012 h.
CMD2: 96.74%, 100.06%, 99.75% average, 0.506, 7 of 150 over 100%; 0.146 h, 11.50 h, 4.24 h average, 2.57 h.
DSFL: 99.59%, 100.05%, 99.75% average, 0.0942, 1 of 24 over 100%; 3.70 h, 5,07 h, 4.38 h average, 0.331 h.
CEP2: 95.62%, 98.67%, 97.39% average, 0.689, 170 tasks; 2.85 h, 12.00 h, 6.56 h average, 2.016 h; 1 task hit 12-hour-cutoff.
FAAH: 97.95%, 100.03%, 99.78% average, 0.234, 1 of 549 tasks over 100%; 3.60h, 9.73h, 5.93 h average, 0.904 h.

All tasks: 94.85%, 101.54%, 99.72% average, 0.569 st.dev, 50 of 4731 tasks over 100%. Min: 0.146 hours cpu-time, max 12.000 hours cpu-time, average 3.25 hours, st.dev 2.24 hours.


Now, getting this info could be made easier if example BoincTask had this capability, but it's also easy to use other tools to get the relevant info. I've probably used longer time typing-out this post than getting the relevant info.

Oh, and for the i7-920, the similar results for CEP2 is:
min 79.91%, 99.14%, 92.38% average, 4.58 st.dev; 4.78 h, 12.000 h, 10.25 h average, 57 of 99 tasks hit the 12-hour cutoff-limit.

No idea how many hours on average is wasted for every time CEP2 cuts-off in the middle of a step, but a 57 % cut-off-rate is definitely too high.

Did not ask you to waste your time... you chose to proof the ''No way'' was contradict-able!

Not really on topic, my *None* HT Q6600 filtering with the WCGDAWS tool of pirogue has had exactly 1 hitting the 12 hour mark in the last 60 days, doing about 6 per day [50% of cores]. From a tech note some week or so ago, there's going to something that will allow these to run up to 24 hours, opt-in was me interpretation and from the statistics, the average run time has actually dropped since the implementation of ZR from 8 hours to 6 hours **, so largely, it's self-inflicted, that high cutoff %. Certainly 57% is not exactly representative, but if it bothers, the None HT crunching by restricting BOINC to the physical cores would possible remove the bulk of your waste, might even increase your number of results... you're good with numbers ;>)

--//--

** Having my thoughts of why that ZR may have added to the mean time drop.