checkpoint_cpu_time higher than current_cpu_time

Message boards : BOINC client : checkpoint_cpu_time higher than current_cpu_time
Message board moderation

To post messages, you must log in.

AuthorMessage
Idefix

Send message
Joined: 27 Jan 06
Posts: 3
Germany
Message 2839 - Posted: 28 Jan 2006, 19:08:58 UTC
Last modified: 28 Jan 2006, 19:10:32 UTC

Hi,

sometimes I notice unreasonable higher cpu times at each of the projects, I'm attached to. I tried to track down the problem during the last week and noticed the following: Sometimes the "checkpoint_cpu_time" of an active task is higher than the "current_cpu_time", which obviously doesn't make any sense ...

Here is an example from my client_state.xml, which I got today, when a SETI@home result was finished and the client switched to SETI@home beta:

<active_task>
<project_master_url>http://setiweb.ssl.berkeley.edu/beta/</project_master_url>
<result_name>05jl01ab.26451.1634.704834.20_0</result_name>
<active_task_state>2</active_task_state>
<app_version_num>502</app_version_num>
<slot>0</slot>
<scheduler_state>2</scheduler_state>
<checkpoint_cpu_time>32792.246000</checkpoint_cpu_time>
<fraction_done>0.158471</fraction_done>
<current_cpu_time>24613.248000</current_cpu_time>
<vm_bytes>0.000000</vm_bytes>
<rss_bytes>0.000000</rss_bytes>
<supports_graphics/>
<graphics_mode_acked>1</graphics_mode_acked>
</active_task>

As you can see, the checkpoint_cpu_time is more than two hours higher than the current_cpu_time.

I'm using trux' optimized 5.3.11.tx32 client, but I also noticed this problem with the standard 5.2.13 client.

As long as the application isn't stopped (the application is left in memory after a project switch, the BOINC client itself isn't stopped) it won't be a problem, because the WU restarts from the current cpu time. But as soon as the application is stopped, the WU restarts from the last checkpoint, and you get a sudden jump of your cpu time.

But this also means, that the system only "pretends" to need higher cpu times. If you measure your real cpu time, it is still normal. But of course, it is very annoying, because the duration correction factor gets messed up (and the result claims to many credits ...).

Is there any way to solve this problem without leaving the computer turned on all the time?

Is it possible to edit the client_state.xml and to copy the correct current_cpu_time to the checkpoint_cpu_time or does it corrupt the result because the client will not find its last checkpoint?

Of course, the best way to solve this problem would be to remove this bug from the client itself ... ;-) (if it is a bug in the client)

Regards,
Carsten

edit: wrong BBCode corrected
ID: 2839 · Report as offensive
Idefix

Send message
Joined: 27 Jan 06
Posts: 3
Germany
Message 3064 - Posted: 15 Feb 2006, 10:37:53 UTC - in response to Message 2839.  
Last modified: 15 Feb 2006, 10:38:49 UTC

Hi,
Is it possible to edit the client_state.xml and to copy the correct current_cpu_time to the checkpoint_cpu_time or does it corrupt the result because the client will not find its last checkpoint?

I've tested it several times and it works. The results are finishing without errors and are getting validated. But of course, it is a realy bad workaround for the problem ...

Regards,
Carsten
ID: 3064 · Report as offensive
Idefix

Send message
Joined: 27 Jan 06
Posts: 3
Germany
Message 3346 - Posted: 4 Mar 2006, 22:42:19 UTC

Sorry for talking to myself ...

Up to now, the problem only occurred on my hosts with Windows 98. But I never noticed it on my host with Windows XP.

Regards,
Carsten
ID: 3346 · Report as offensive

Message boards : BOINC client : checkpoint_cpu_time higher than current_cpu_time

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.