I got a new notebook about a month ago and have 6.12.33(x64) running on it. Although I am a relatively experienced BOINC user, there are several aspects of this notebook's BOINC operation that are new to me. That is, it is my first computer with Windows 7, my first computer with a GPU and my first experience running BOINC 6.12.33. Therefore, I am not sure whether what I am about to describe is a BOINC "bug" or a BOINC "feature" combined with an "operator malfunction".

My BOINC installation is returning results immediately - and when I say immediately, I mean IMMEDIATELY. That is, event logs indicate results are being reported one second after the upload is finished (as opposed to the one minute delay, I thought the feature was supposed to use). I did nothing (intentionally) to implement "report results immediately". Furthermore, it seems that this starts happening only after BOINC has been running for some time. That is, I have thought I have fixed the problem by restarting the computer, but - it starts doing it again eventually.

Any thoughts and/or suggestions are welcome.

There is a new feature in v6.12.33, that when a project is set to 'No new tasks' it is also, and automatically, set to report results immediately.

The idea is that when BOINC is running normally, it is allowed to fetch work as and when needed: but people sometimes know better than BOINC can that, say, a vacation is imminent. If they set NNT in anticipation, without work fetch completed work wouldn't be reported - and sometimes it isn't reported until after the vacation, which can be too late. Hence, the clearout of completed work as it happens. Could you be, inadvertently, invoking that rule?

There is a new feature in v6.12.33, that when a project is set to 'No new tasks' it is also, and automatically, set to report results immediately.

The idea is that when BOINC is running normally, it is allowed to fetch work as and when needed: but people sometimes know better than BOINC can that, say, a vacation is imminent. If they set NNT in anticipation, without work fetch completed work wouldn't be reported - and sometimes it isn't reported until after the vacation, which can be too late. Hence, the clearout of completed work as it happens. Could you be, inadvertently, invoking that rule?

Thanks Richard! I regularly use NNT and was not aware of the new feature in v6.12.33. But, what about the "one minute" delay? Is that not needed anymore?

I've noticed another aspect to the way v6.12.33 is reporting results without any delay. That is, when a project is out of work and my computer has finished the last task in cache from that project, my computer reports that task 0 to 3 seconds after it has finished uploading it (at the same time it requests new work). I've seen this happen with both Seti and Milkyway recently. Here's an example from Milkyway:

8/2/2011 6:54:28 PM | Milkyway@home | Computation for task ps_separation_10_3s_fix10_2_1459048_2 finished
8/2/2011 6:54:28 PM | Einstein@Home | Resuming task h1_0310.25_S6GC1__1116_S6BucketA_0 using einstein_S6Bucket version 101
8/2/2011 6:54:28 PM | Milkyway@home | Sending scheduler request: To fetch work.
8/2/2011 6:54:28 PM | Milkyway@home | Reporting 1 completed tasks, requesting new tasks for CPU

As I asked in the post below, shouldn't BOINC be using a one minute delay before reporting results? I know that, a few years ago, some results were being lost because they were being reported too soon and a one minute delay was implemented to fix that problem. Is the delay no longer necessary or does v6.12.33 need to be fixed? (I would note that, so far anyway, all my "early" reported results have been OK.)

I've never been quite sure how much of a deliberate BOINC development policy that was.

There's a one minute backoff after a task ends in a computation error, but I agree with you - I'd have thought it would be a good idea to do something similar after a 'success' outcome too.

There is now - again, new in v6.12.xx - a pause while the result file with the outcome of the task is uploaded. There's no sign of that in your log - are you sure that this scheduler request wasn't reporting a previous task?

I've never been quite sure how much of a deliberate BOINC development policy that was.

Now that I think about it, I believe the one minute delay was a fix to one of Crunch3r's optimized BOINC clients (obviously, a long time ago). But, it was in response to an identified "reporting too early" problem.

There's no sign of that in your log - are you sure that this scheduler request wasn't reporting a previous task?

Yes, I am sure. Both Seti and Milkyway have had alot of "No work available" periods lately. And, I've seen this "immediate reporting" of the last task in cache on both projects. (Unfortunately, I've restarted since posting - so the logs are gone.)

Logs are written to the stdoutdae.txt file in your BOINC Data directory.

---

I'm seeing Boinc 6.12.34 start reporting before the last upload is complete (with NNT set), i'm sure 6.12.x is supposed to package them up into one report:

03/08/2011 12:12:45 Einstein@Home Started upload of h1_0310.55_S6GC1__1203_S6BucketA_0_0
03/08/2011 12:12:45 Einstein@Home Started upload of h1_0310.60_S6GC1__1252_S6BucketA_1_0
03/08/2011 12:12:57 Einstein@Home Finished upload of h1_0310.55_S6GC1__1203_S6BucketA_0_0
03/08/2011 12:12:57 Einstein@Home Finished upload of h1_0310.60_S6GC1__1252_S6BucketA_1_0
03/08/2011 12:12:57 Einstein@Home Started upload of h1_0310.70_S6GC1__1084_S6BucketA_1_0
03/08/2011 12:12:59 Einstein@Home [sched_op] Starting scheduler request
03/08/2011 12:12:59 Einstein@Home Sending scheduler request: To report completed tasks.
03/08/2011 12:12:59 Einstein@Home Reporting 2 completed tasks, not requesting new tasks
03/08/2011 12:12:59 Einstein@Home [sched_op] CPU work request: 0.00 seconds; 0.00 CPUs
03/08/2011 12:12:59 Einstein@Home [sched_op] NVIDIA GPU work request: 0.00 seconds; 0.00 GPUs
03/08/2011 12:13:09 Einstein@Home Finished upload of h1_0310.70_S6GC1__1084_S6BucketA_1_0
03/08/2011 12:13:09 Einstein@Home Scheduler request completed
03/08/2011 12:13:09 Einstein@Home [sched_op] Server version 611
03/08/2011 12:13:09 Einstein@Home Project requested delay of 60 seconds
03/08/2011 12:13:09 Einstein@Home [sched_op] handle_scheduler_reply(): got ack for task h1_0310.60_S6GC1__1252_S6BucketA_1
03/08/2011 12:13:09 Einstein@Home [sched_op] handle_scheduler_reply(): got ack for task h1_0310.55_S6GC1__1203_S6BucketA_0
03/08/2011 12:13:09 Einstein@Home [sched_op] Deferring communication for 1 min 0 sec
03/08/2011 12:13:09 Einstein@Home [sched_op] Reason: requested by project
03/08/2011 12:14:14 Einstein@Home [sched_op] Starting scheduler request
03/08/2011 12:14:14 Einstein@Home Sending scheduler request: To report completed tasks.
03/08/2011 12:14:14 Einstein@Home Reporting 1 completed tasks, not requesting new tasks
03/08/2011 12:14:14 Einstein@Home [sched_op] CPU work request: 0.00 seconds; 0.00 CPUs
03/08/2011 12:14:14 Einstein@Home [sched_op] NVIDIA GPU work request: 0.00 seconds; 0.00 GPUs
03/08/2011 12:14:27 Einstein@Home Scheduler request completed
03/08/2011 12:14:27 Einstein@Home [sched_op] Server version 611
03/08/2011 12:14:27 Einstein@Home Project requested delay of 60 seconds
03/08/2011 12:14:27 Einstein@Home [sched_op] handle_scheduler_reply(): got ack for task h1_0310.70_S6GC1__1084_S6BucketA_1
03/08/2011 12:14:27 Einstein@Home [sched_op] Deferring communication for 1 min 0 sec
03/08/2011 12:14:27 Einstein@Home [sched_op] Reason: requested by project

Claggy

Another example of immediate reporting:

8/4/2011 7:42:30 AM | SETI@home | Finished upload of 14mr11ab.692.21744.13.10.161_1_0
8/4/2011 7:42:30 AM | SETI@home | Sending scheduler request: To fetch work.
8/4/2011 7:42:30 AM | SETI@home | Reporting 1 completed tasks, requesting new tasks for CPU
8/4/2011 7:42:33 AM | SETI@home | Scheduler request completed: got 1 new tasks
8/4/2011 7:42:35 AM | SETI@home | Started download of 03ap11ad.21638.290794.12.10.183

I think I've noticed another difference in the way v6.12.33 is operating as compared to earlier BOINC versions. That is, other versions of BOINC would have requested new work from Seti before the last task in cache had finished. BOINC v6.12.33 waited until the last task finished and uploaded - then it (immediately) requested new work and reported the completed task at the same time. (I looked at my event log for several hours prior to the above entries and verified that BOINC had not requested work from Seti during that time.)

I just had a MW unit fail to validate after reporting 2 seconds after finishing (and NNT was not set).

Event log:

8/21/2011 9:04:24 PM | Milkyway@home | Computation for task ps_separation_82_2s_mix0_1_1170906_0 finished
8/21/2011 9:04:24 PM | Test4Theory@Home | Resuming task uc_1313873249_238_0 using cernvm version 603
8/21/2011 9:04:26 PM | Milkyway@home | Sending scheduler request: To fetch work.
8/21/2011 9:04:26 PM | Milkyway@home | Reporting 1 completed tasks, requesting new tasks for CPU
8/21/2011 9:04:28 PM | Milkyway@home | Scheduler request completed: got 1 new tasks

Error text:

<core_client_version>6.12.33</core_client_version>
<![CDATA[
<stderr_txt>
Error loading Lua script 'astronomy_parameters.txt': [string "number_parameters: 4..."]:1: '<name>' expected near '4'
Error reading astronomy parameters from file 'astronomy_parameters.txt'
Trying old parameters file
Using SSE3 path

</stderr_txt>
]]>

And what would that error have to do with the immediate reporting?

The stderr gets written even before the task is uploaded let alone reported.

Gruß,
Gundolf