I'm currently (and briefly - for CUDA testing only) using the deprecated "<report_results_immediately>" option.

According to the documentation, reporting should happen "with an inbuild 60 second delay from completion of result upload".

This isn't happening:

21-Jan-2009 10:15:57 [SETI@home Beta Test] Computation for task 03no08aa.22996.277095.7.11.62_1 finished
21-Jan-2009 10:16:00 [SETI@home Beta Test] Started upload of 03no08aa.22996.277095.7.11.62_1_0
21-Jan-2009 10:16:05 [SETI@home Beta Test] Finished upload of 03no08aa.22996.277095.7.11.62_1_0
21-Jan-2009 10:16:09 [SETI@home Beta Test] Sending scheduler request: To report completed tasks.  Requesting 0 seconds of work, reporting 1 completed tasks
21-Jan-2009 10:16:14 [SETI@home Beta Test] Scheduler request completed: got 0 new tasks

21-Jan-2009 10:14:43 [SETI@home] Computation for task ap_01dc08ab_B2_P1_00057_20090107_28452.wu_3 finished
21-Jan-2009 10:14:46 [SETI@home] Started upload of ap_01dc08ab_B2_P1_00057_20090107_28452.wu_3_0
21-Jan-2009 10:14:51 [SETI@home] Finished upload of ap_01dc08ab_B2_P1_00057_20090107_28452.wu_3_0
21-Jan-2009 10:14:53 [SETI@home] Sending scheduler request: To report completed tasks.  Requesting 0 seconds of work, reporting 1 completed tasks
21-Jan-2009 10:14:58 [SETI@home] Scheduler request completed: got 0 new tasks

21-Jan-2009 08:45:02 [SETI@home Beta Test] Finished upload of 03no08aa.22996.276686.7.11.236_1_0
21-Jan-2009 08:45:06 [SETI@home Beta Test] Sending scheduler request: To report completed tasks.  Requesting 0 seconds of work, reporting 1 completed tasks

21-Jan-2009 07:13:47 [SETI@home Beta Test] Finished upload of 03no08aa.22996.276686.7.11.198_0_0
21-Jan-2009 07:13:49 [SETI@home Beta Test] Sending scheduler request: To report completed tasks.  Requesting 0 seconds of work, reporting 1 completed tasks

and so on. More like 2 to 4 seconds delay, instead of the advertised 60. BOINC v6.4.5

I might make a trac ticket of this later, when the BOINC server isn't so perishingly slow.

I might make a trac ticket of this later, when the BOINC server isn't so perishingly slow.

Trac isn't slow for me. Not any slower than it usually is, anyway.

---

I might make a trac ticket of this later, when the BOINC server isn't so perishingly slow.

Trac isn't slow for me. Not any slower than it usually is, anyway.

OK, when I get back from my on-site callout, then. Got to go now.

I'm currently (and briefly - for CUDA testing only) using the deprecated "<report_results_immediately>" option.

According to the documentation, reporting should happen "with an inbuild 60 second delay from completion of result upload".

I checked in Trac for when this option was put back in. It doesn't say in the changeset that it waits 60 seconds. Wasn't that an option in Crunch3r's version anyway?

See [trac]changeset:14666[/trac], where it says:
"client: added <report_results_immediately> configuration flag;
causes results to be reported as soon as done.
Needed for some WCG machines that are reformatted often.
Should NOT be used in general, since it increases server load."

---

That's why I linked to the documentation (Wiki), where the 60-second delay is mentioned. I find, in general, that it's better if software documentation matches the software itself ;-)

In this case, I think the documentation is the better option. You're right: Crunch3r put RRI into his v6.1.0 client (which is actually a v5.x.x client - can't be installed over a v6 BOINC. But I digress).

There were actually, I think, up to 5 different Crunch3r releases all under the v6.1.0 banner. The early ones did indeed report results immediately, and this caused problems with validate errors (the report arrived before the servers had digested the upload). Crunch3r was prevailed upon to build the 60-second delay into later iterations of the v6.1.0 line, and things have gone much more smoothly since then. I think it would be helpful if the stock client could follow Crunch3r's example, and its own documentation, in this case.

That's why I linked to the documentation (Wiki), where the 60-second delay is mentioned. I find, in general, that it's better if software documentation matches the software itself ;-)

The trouble is that the documentation in that Wiki is kept up-to-date by volunteers, not the developers. So I think this is a case of mistaken identity, where the user who added that bit of text had crunch3r's version in mind.

Not to say you can't try to get this changed, though. :-)

---

That's why I linked to the documentation (Wiki), where the 60-second delay is mentioned. I find, in general, that it's better if software documentation matches the software itself ;-)

The trouble is that the documentation in that Wiki is kept up-to-date by volunteers, not the developers. So I think this is a case of mistaken identity, where the user who added that bit of text had crunch3r's version in mind.

Not to say you can't try to get this changed, though. :-)

Looking at it (now borrowing a client's machine, waiting while their new PC downloads the initial 130MB security updates for a new Vista deployment :-( ), the issue overlaps with trac [trac]#728[/trac], where report_results_immediately is explicitly requested to adhere to the proposed delay.

Unfortunately, both in that ticket and in the related thread 3092, people - including David Anderson - misunderstood the question, thinking that people were talking about a scheduler contact to report the current task, before the current task upload had completed. They weren't.

The problem in that ticket/thread concerned a scheduler contact to fetch work, happening in parallel with an upload for a task just finished. Because the scheduler contact is initated by the client, as a new request, project-mandated backoffs don't (yet) apply, contrary to what some people were trying to say. But now that David has written it off, it might be easier to get this RRI delay accepted as a new enhancement. Or would that finally destroy any chance of getting the more general delay accepted? Suggestions?

Try it, I would say. We have a saying here which goes "No you have already, Yes is possible to get". There's probably something alike that in English, but I am lazy. ;-)

---