Message boards : BOINC client : checkpoint_cpu_time higher than current_cpu_time
Message board moderation
Author | Message |
---|---|
Send message Joined: 27 Jan 06 Posts: 3 |
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 |
Send message Joined: 27 Jan 06 Posts: 3 |
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 |
Send message Joined: 27 Jan 06 Posts: 3 |
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 |
Copyright © 2025 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.