Jean, what you see anywhere in BOINC in terms of 'run time' is the time the process was able to get from the CPU, not any wall clock time. If you go to BOINCview or dig into the client_state.xml file you can actually find the CPU efficiency being the ratio of wall clock time versus CPU time obtained. The closer that number is to 1, the higher the efficiency is that BOINC operates at. It indicates the portion BOINC has been able to obtain from total CPU time. e.g. my working desktop runs momentarily at 0.68 = 68%. My C2D laptop runs at 0.9991 i.e. 99.91%, momentarily. This value includes any throttling.

If you let BOINC process run uninterruptedly and you look in the process/task manager of your OS you will see the absolute identical CPU time reported as what's shown in BOINC, so unless the OS miscalculates the actual seconds or part there-off I'm reasonably comfortable that the reported times by BOINC client is correct.

Summary: Elapsed time = Real CPU time of the Task Tab is the time that will be reported to WCG and is shown on the Result Status page.

Separately, the benchmarks is a very flawed value and if a 5.10.17 client meets a 5.8 with a wobble and they have, for the measured integer test can by 1/2 or 1/3 or worse at times on a dual core machine, it looks horrible. Moreover in HPF2, Linux and Mac Intel meet Windows. Their benchmarks truly can be all over the place.... a 5.4 Linux only giving 55% of a 5.4 Windows e.g. And really there are monsters around that chop up these jobs in under 3 hours.

oh and what you see in claim on the Result Status page is not the absolute value you submitted. It's adjusted to your historic claim average per second of the last 15-20 results submitted (for the specific machine).

cheers

Correct, "Elapsed time" is a misnomer. BOINC measures CPU time, as reported by the operating system.

While the CPU time is mostly independent of other running processes, there are a few things that affect it. In particular: disk contention or excessive swapping, and cache contention.

If you were doing something daft like running multiple crunching processes on a hyperthreaded CPU, then contention would be high, and you would see some unexpectedly high CPU times. This is why hyperthreading doesn't give any benefit for crunching WCG projects.