| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: BOINC Agent Support
Thread: report_deadline is always zero [RESOLVED] |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 12
|
|
| Author |
|
|
docker7
Cruncher Joined: Feb 23, 2011 Post Count: 7 Status: Offline |
Hello,
----------------------------------------For some reason all my clients run under FreeBSD got <report_deadline> values equal to zero. This happened when I reinstalled all ports needed for to run WCG on FreeBSD. This issue happened with already downloaded tasks and with new tasks. I'm trying to find the source of this mistake, but could not so far. Can somebody help me with the following questions. Which application does specify report_deadline value in client_state.xml? According to boinc source code (I use 6.4.5 version) it only parses this value, "report_deadline" string also does not exist in Linux binary programs downloaded from WCG. If I update this value manually, then boinc correctly adjusts report deadline for each task. (please do not suggest to reinstall boinc, remove boinc directory, I already have done this and above described issue is still here). Thanks. [Edit 1 times, last edit by docker7 at May 8, 2012 9:20:29 AM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
 In BOINC Manager under Task Properties, Received and Report Deadline are shown in the same format. Any differences in how they appear on your machine? Lawrence |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
The deadline date/time comes with a task header file as an offset to the current time of your system. If the deadline is 10 days and your system date would be set to 20 March, then the deadline becomes 30 March. No deadline/deadline expired would imply that tasks are processing in high priority. 65,000 USD question is, what deadline shows on the My Grid > Result Status page for these tasks? Those are the once to be met, in UTC time, regardless of whatever your system date/times are.
----------------------------------------Not going to ask you to reinstall. 6.4.5 is aged, where the WCG recommended level is 6.10.58. --//-- edit: the last Linux received task shows the below. The bolded number includes offset since 1.1.1970 at 00:00 UTC, in seconds, which equates for the below to a due at 42.27 years since that date (which principle I'm sure you know). <result> <name>DSFL_000010-6_0000049_0205_1</name> <final_cpu_time>0.000000</final_cpu_time> <final_elapsed_time>0.000000</final_elapsed_time> <exit_status>0</exit_status> <state>2</state> <platform>windows_intelx86</platform> <version_num>624</version_num> <wu_name>DSFL_000010-6_0000049_0205</wu_name> <report_deadline>1333971458.000000</report_deadline> <received_time>1333107473.034094</received_time> <file_ref> <file_name>DSFL_000010-6_0000049_0205_1_0</file_name> <open_name>result.out</open_name> </file_ref> </result> edit2: So what is the <received_time> printing now in seconds? [Edit 2 times, last edit by Former Member at Mar 30, 2012 12:25:19 PM] |
||
|
|
docker7
Cruncher Joined: Feb 23, 2011 Post Count: 7 Status: Offline |
My BOINC Manager does not show Received time, according to its source code, it does not show such column. "To completion" column has date 1st January 1970, and this value is obvious since report_deadline is zero.
|
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
See my edits of previous reply.
--//-- |
||
|
|
docker7
Cruncher Joined: Feb 23, 2011 Post Count: 7 Status: Offline |
The deadline date/time comes with a task header file as an offset to the current time of your system. If the deadline is 10 days and your system date would be set to 20 March, then the deadline becomes 30 March. No deadline/deadline expired would imply that tasks are processing in high priority. 65,000 USD question is, what deadline shows on the My Grid > Result Status page for these tasks? Those are the once to be met, in UTC time, regardless of whatever your system date/times are. That was the first step, when I saw this issue. According to WCG web site all dates are correct.Not going to ask you to reinstall. 6.4.5 is aged, where the WCG recommended level is 6.10.58. I just use BOINC from FreeBSD ports collection, and it worked correctly for one year. BOINC compiled for Linux did not work, so I decided to build native BOINC for my system.edit2: So what is the <received_time> printing now in seconds? BOINC source code and BOINC database with projects do not have "received_time" string on my systems.Here are some lines from client_state.xml: <result> <name>faah31985_ZINC12242602_x3NF6b_00_0</name> <final_cpu_time>0.000000</final_cpu_time> <exit_status>0</exit_status> <state>2</state> <platform>i686-pc-linux-gnu</platform> <version_num>640</version_num> <wu_name>faah31985_ZINC12242602_x3NF6b_00</wu_name> <report_deadline>0.000000</report_deadline> <file_ref> <file_name>faah31985_ZINC12242602_x3NF6b_00_0_0</file_name> <open_name>./wcg_ad4-result.xml</open_name> </file_ref> <file_ref> <file_name>faah31985_ZINC12242602_x3NF6b_00_0_1</file_name> <open_name>./wcg_autodock4.dlg</open_name> </file_ref> <file_ref> <file_name>faah31985_ZINC12242602_x3NF6b_00_0_2</file_name> <open_name>./md5sum</open_name> <optional/> </file_ref> <file_ref> <file_name>faah31985_ZINC12242602_x3NF6b_00_0_3</file_name> <open_name>./wcgrid_benchmark-result.xml</open_name> <optional/> </file_ref> </result> |
||
|
|
docker7
Cruncher Joined: Feb 23, 2011 Post Count: 7 Status: Offline |
Just found out that there is sched_reply_www.worldcommunitygrid.org.xml file that has correct <report_deadline> values (in seconds since the Epoch). I'm going to verify how does BOINC use report_deadline from this file, and why report_deadline always is zero in client_state_xml. Previously I added debug messages to BOINC and it really set sreport_deadline to zero.
Thanks to everyone, I need some time to check BOINC source code. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Do you recollect the exact date when this started and are you sure it was not already the case before your reinstalls? Also, you can confirm that these FreeBSD systems continue to receive and return work. I'm looking at BOINCStats and see credit was recorded for the last 4 days, nothing for the 3 days prior to that.
------------------------------------------//-- edit: Oh yes, do your FreeBSD systems get new work before it finishes the currently running tasks? [Edit 1 times, last edit by Former Member at Mar 30, 2012 1:32:02 PM] |
||
|
|
docker7
Cruncher Joined: Feb 23, 2011 Post Count: 7 Status: Offline |
Do you recollect the exact date when this started and are you sure it was not already the case before your reinstalls? Also, you can confirm that these FreeBSD systems continue to receive and return work. I'm looking at BOINCStats and see credit was recorded for the last 4 days, nothing for the 3 days prior to that. I did not see any issues with both my clients (two systems under FreeBSD/amd64 of the same version) for one year. I updated packages on one system and got strange times values in BOINC manager, then I waited several weeks and reinstalled packages on another system that previously showed correct times values in BOINC manager, as a result BOINC manager adjusted times values to incorrect values even for already downloaded tasks. I did not find any changes in packages required for BOINC and for Linux compatibility mode, according to repository all these packages have the same version as before.Looks like that this issue is not related to Linux programs from WCG, since these times are calculated inside BOINC (that is a native FreeBSD application on my system). I'm going to add debug messages to BOINC source code and to find the reason. My systems are not working full time, so sometimes it takes more time to finish WU. edit: Oh yes, do your FreeBSD systems get new work before it finishes the currently running tasks? Yes, as usual. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Thanks for that. Coupled with you establishing that various scheduling files on your comp do get the correct deadline downloaded, this kind of eliminates the server upgrade to level 700 on March 6 as cause, since your second FreeBSD was not affected until you rebuild that one some weeks later. There was an issue with ever inflated deadlines... they went to 12-16-31 even a year, but that was fixed, so except for HCC, all new tasks (original quorum) are with a deadline of 10 days and repairs have 4 days [slow systems that are timely returners get a bit more, as an aside].
------------------------------------------//-- edit: The receipt of new work before others are finishing indicates that buffering continues to work as per your client settings. [Edit 1 times, last edit by Former Member at Apr 2, 2012 11:19:04 AM] |
||
|
|
|