Trying to undestand credit calculation.

5XL1970
5XL1970
Joined: 31 Jul 10
Posts: 3
Credit: 3618193
RAC: 0
Topic 195225

I am crunching WU in my Laptop computer and i can see than usually, a WU need 29k seconds to finish (Global Correlations S5 search #1 v3.02 (S5GCESSE2). I use all of the time and all of the 4 threads of the CPU (i5 CPU M 430 @ 2.27GHz), but sometimes, a WU need only 7k seconds of run time, but 29k seconds of CPU time.

What´s wrong with this WU? The project give me the same amound of credits that other WU, but I want to know what happens with these WU.

Thank you in advance.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5883
Credit: 119064921340
RAC: 24458249

Trying to undestand credit calculation.

Quote:

... but sometimes, a WU need only 7k seconds of run time, but 29k seconds of CPU time.

What´s wrong with this WU?


There is nothing wrong with any of the tasks that show a 7K runtime.

When you look at your list of results for that machine, you can see that most show a CPU time of 29K seconds with the 'Run time' (ie total elapsed time) about 100 seconds longer. This is perfectly normal as it shows that a CPU core did 100 secs of other work during the running of a complete task. This applies if the task is computed continuously without suspension by say the task of another project or by the machine being shut down.

If you have selected the BOINC preference to 'keep jobs in memory when suspended' then you would not lose the recording of the total elapsed time for a particular task that might be suspended at some point. If you don't have this preference set, or if you completely restart your computer, a task would need to be restarted from a saved checkpoint and I'm guessing that a checkpoint doesn't contain a record of the previous runtime. So, in this event, the runtime would be started from zero whilst the CPU time would continue on from the restored value that was saved in the checkpoint. This would be why you are seeing the odd low runtime values.

You can check this for yourself by clicking on the taskID of one of your affected tasks. You can find where the task was restarted from a checkpoint and you can use the embedded times to check that the 7K seconds actually agrees closely with the time from the restart to the end of the task.

So the 'problem' is entirely cosmetic and you are always awarded the correct credit.

Cheers,
Gary.

5XL1970
5XL1970
Joined: 31 Jul 10
Posts: 3
Credit: 3618193
RAC: 0

Ah, ok. I undestand now what

Ah, ok. I undestand now what happens with these WUs.
Thanks a lot for the rapid answer, Gary.

Good night from southern Spain.

Jord
Joined: 26 Jan 05
Posts: 2952
Credit: 5893653
RAC: 0

RE: If you don't have this

Message 98826 in response to message 98824

Quote:
If you don't have this preference set, or if you completely restart your computer, a task would need to be restarted from a saved checkpoint and I'm guessing that a checkpoint doesn't contain a record of the previous runtime.


Checkpoints (in the slot\X\ directory, where the X is the slot for Einstein) are saved in the boinc_task_state.xml file and hold the following information:

    http://einstein.phys.uwm.edu/
    h1_0918.95_S5R4__459_S5GC1a_2
    23400.030000
    23812.997068
    0.977218


(e.g. from one of my own)

5XL1970
5XL1970
Joined: 31 Jul 10
Posts: 3
Credit: 3618193
RAC: 0

Thanks too for you Ageless.

Thanks too for you Ageless.

Usually I turn off the laptops during the hours of more hot here during the summer because i have no refrigeration system in the room where the computers are and the CPU cores raise to 85º C.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.