Status: Missed in History Tab

Started by merko, August 25, 2011, 02:26:29 AM

Previous topic - Next topic

0 Members and 4 Guests are viewing this topic.

merko

What does this status mean:

World Community Grid   6.40 Help Fight Childhood Cancer   HFCC_target-7_00231620_target-7_0001_0   07:41:11 (06:26:17)   8/24/2011 7:44:13 PM   8/24/2011 7:44:13 PM      Missed   M-7b   

fred

Quote from: merko on August 25, 2011, 02:26:29 AM
What does this status mean:

World Community Grid   6.40 Help Fight Childhood Cancer   HFCC_target-7_00231620_target-7_0001_0   07:41:11 (06:26:17)   8/24/2011 7:44:13 PM   8/24/2011 7:44:13 PM      Missed   M-7b
Means BoincTasks didn't see the task complete (in upload or completed). It may be that BoincTasks wasn't running at that time or the tasks was gone before BT could see it.

hucker

How do I make it not miss things?  It's missing every single Milkyway task.  I thought the tasks were being reported too late!

Pepo

Quote from: hucker on November 10, 2011, 09:13:50 PM
How do I make it not miss things?  It's missing every single Milkyway task.
Let's take the MilkyWay example. You have a few options:

  • When the MW tasks approach 100% progress (the last 2-3 minutes), does the Progress% update frequently enough, so that the Remaining time nicely counts down to zero minutes? If there are at least 4-5 steps in the last minute, then checking the "Smart mode" in the History prefs should do  the job.
  • Take a look into your Event log, where MW tasks finish computation, make uploads, start reporting finished tasks and the scheduler requests are finished. It takes usually at least 5-6 seconds from finishing a task until the subsequent scheduler request is completed, but more common delay times are a couple of tens of seconds. If you set the History's maximum refresh interval value some 1-2 seconds below the usual delay time, you should catch the majority of the tasks in either Uploading or Ready to report state, and get much less Missed MW tasks.
    A drawback of low max refresh time is unnecessarily higher CPU or network usage.
The History's minimum refresh interval is probably fine at some 3-5 seconds. It is being used when the Smart mode rmporarily makes History snooping faster than the maximum refresh interval preference.
Peter

hucker

Quote from: Pepo on November 10, 2011, 11:10:10 PM
When the MW tasks approach 100% progress (the last 2-3 minutes), does the Progress% update frequently enough, so that the Remaining time nicely counts down to zero minutes? If there are at least 4-5 steps in the last minute, then checking the "Smart mode" in the History prefs should do the job.

They are ATI tasks and take about 5 minutes to complete.  The progress is updated every few seconds.  Smart mode is on.

Quote from: Pepo on November 10, 2011, 11:10:10 PM
Take a look into your Event log, where MW tasks finish computation, make uploads, start reporting finished tasks and the scheduler requests are finished. It takes usually at least 5-6 seconds from finishing a task until the subsequent scheduler request is completed, but more common delay times are a couple of tens of seconds. If you set the History's maximum refresh interval value some 1-2 seconds below the usual delay time, you should catch the majority of the tasks in either Uploading or Ready to report state, and get much less Missed MW tasks.

3567   Milkyway@home   10/11/2011 11:27:40 pm   Computation for task ps_separation_13_3s_fix20_2_6216322_0 finished   
3568   Milkyway@home   10/11/2011 11:27:40 pm   Starting task ps_separation_10_3s_fix20_2_6217161_0 using milkyway version 82   
3569   Milkyway@home   10/11/2011 11:27:43 pm   Sending scheduler request: To fetch work.   
3570   Milkyway@home   10/11/2011 11:27:43 pm   Reporting 1 completed tasks, requesting new tasks for ATI GPU   
3571   Milkyway@home   10/11/2011 11:27:45 pm   Scheduler request completed: got 1 new tasks   

It took 5 seconds.  I've set history to 1 second and 1 second.  Still missing some.

Funny, no upload?  If a task only has a simple answer to give maybe there is no upload file and the data is inside the report?

Quote from: Pepo on November 10, 2011, 11:10:10 PM
A drawback of low max refresh time is unnecessarily higher CPU or network usage.

Not on this computer :-)  24GB RAM, twin terrabyte Caviar black hard disks, i7 940 @ 5GHz watercooled.

Pepo

Quote from: hucker on November 10, 2011, 11:33:25 PM
Quote from: Pepo on November 10, 2011, 11:10:10 PM
Take a look into your Event log, where MW tasks finish computation, make uploads, start reporting finished tasks and the scheduler requests are finished. It takes usually at least 5-6 seconds from finishing a task until the subsequent scheduler request is completed, but more common delay times are a couple of tens of seconds. If you set the History's maximum refresh interval value some 1-2 seconds below the usual delay time, you should catch the majority of the tasks in either Uploading or Ready to report state, and get much less Missed MW tasks.

3567   Milkyway@home   10/11/2011 11:27:40 pm   Computation for task ps_separation_13_3s_fix20_2_6216322_0 finished   
3568   Milkyway@home   10/11/2011 11:27:40 pm   Starting task ps_separation_10_3s_fix20_2_6217161_0 using milkyway version 82   
3569   Milkyway@home   10/11/2011 11:27:43 pm   Sending scheduler request: To fetch work.   
3570   Milkyway@home   10/11/2011 11:27:43 pm   Reporting 1 completed tasks, requesting new tasks for ATI GPU   
3571   Milkyway@home   10/11/2011 11:27:45 pm   Scheduler request completed: got 1 new tasks   

It took 5 seconds.  I've set history to 1 second and 1 second.  Still missing some.
:o This would mean that the task disappeared prior to the scheduler request. I suspect this is not possible.
I can not recall, which cc_config flag causes logging of "Got ack for task XXXXXXXX" message, possibly <task_debug>. The client is discarding a task after displaying this message. So, until this message appears after completing a sched request, a finished task should be still seen and available for history?

QuoteFunny, no upload?  If a task only has a simple answer to give maybe there is no upload file and the data is inside the report?
I think this might be possible.
Peter

hucker

Quote from: Pepo on November 11, 2011, 01:28:56 AM
:o This would mean that the task disappeared prior to the scheduler request. I suspect this is not possible.
I can not recall, which cc_config flag causes logging of "Got ack for task XXXXXXXX" message, possibly <task_debug>. The client is discarding a task after displaying this message. So, until this message appears after completing a sched request, a finished task should be still seen and available for history?

How do I provide further information on this?  I've never debugged BOINC or BOINC tasks, or anything else for that matter..

fred


Pepo

Quote from: Pepo on November 11, 2011, 01:28:56 AM
I can not recall, which cc_config flag causes logging of "Got ack for task XXXXXXXX" message, possibly <task_debug>. The client is discarding a task after displaying this message.
I believe it is the <sched_op_debug> log flag. Try to add at least this subset of BOINC loging flags into the cc_config.xml file (which resides (or have to be created) in BOINC data folder (which location can be found among the first lines of the Event log, as "Data directory: C:\ProgramData\BOINC")):
Code (cc_config.xml) Select

<cc_config>
    <log_flags>
        <file_xfer>1</file_xfer>
        <sched_ops>1</sched_ops>
        <task>1</task>
        <sched_op_debug>1</sched_op_debug>
    </log_flags>
</cc_config>
Peter

hucker


hucker

Damn it, can't tell you if it worked now, I changed graphics card (to a newer one) and this one apparently doesn't do double precision maths?!?  How can a newer one do LESS functions?!?

Tom_unoduetre

I also have some WU with Missed in History tab, I just installed latest beta 1.27 and have set both minimum refresh interval and maximum refresh interval to 2, let´s see how this develops.