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
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.
How do I make it not miss things? It's missing every single Milkyway task. I thought the tasks were being reported too late!
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.
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.
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.
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..
Try using V 1.26 http://www.efmer.eu/boinc/boinc_tasks/download_beta.html (http://www.efmer.eu/boinc/boinc_tasks/download_beta.html)
I made some changes to avoid misses.
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 (http://boinc.berkeley.edu/trac/wiki/ReportBugs) 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")):
<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>
Quote from: fred on November 11, 2011, 11:57:11 AM
Try using V 1.26 http://www.efmer.eu/boinc/boinc_tasks/download_beta.html (http://www.efmer.eu/boinc/boinc_tasks/download_beta.html)
I made some changes to avoid misses.
Testing......
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?!?
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.