Sorry all... my eyes are going downhill... the title of above should read ..."Ready to report".

Cheers

Hi SekeRob..

Thanks for the feedback..
The BOINC version is 6.10.58
The wxWidgets version is 2.8.10

I must admit that the "forever" term was probably an exageration.. I recall that last year - probably about a month ago, this "delayed" reporting didn't seem to happen.. I've only noticed it recently... my daily average output has dropped, and thats what alerted me. I've been too impatient to let it go and see what happens at 24hrs... I will do that and check.

Many Thanks.

One apparent reason could be: What's your cache/buffer settings like and how variable is the actual buffer size over and above the minimum setting you've entered? Example:

Buffer 3 days. One task that arrived took not 4 projected hours but 8. Recalc of cache now considers all other buffered tasks [for WCG] to take twice as long too, so the actual buffer actually expands also by that factor... client wont fetch work until next the total drops below 3 days total time to completion.

That's part of the answer if not whole. If there is no fetch requirement, the client reverts to the 24 hour rule, no matter how often you hit the update button only sooner if the RtR is under deadline threat.

Does it matter when results get reported today or tomorrow when the deadline is another 4-7 days in the future? No, not one iota as far as BOINC is concerned or WCG! No, because only a fraction of the member hits buttons and thus it has little to no impact on total jobs that are IP or PV. WCG in general allows 7 to 10 days, only for repair jobs/beta 2.8 to 4 days (in the rare occasion a repair job of a beta gets 1.6 days, but these only go to "reliable" hosts that on average return work anyhow within 48 hours).

Long as your client keeps fetching work with the defaults, you only mention reporting "might be several days in a row where I have to manually perform a project update to report finished and uploaded WUs", there's no "have to" either ;>)

Crunchers have higher pursuits to engage with worthy of their contribution to the grid than to delve into details of whatever mechanisms or processes (that apparently failed) were involved between BOINC and the servers -- and next, from that understanding, for a cruncher to begin to act out a proposed solution.

A BOINC 'janitor' process at the client-side needs to be created to clean up whatever mess that BOINC, WCG, or any other external processes created (or dumped) at a client's BOINC. A counterpart WCG BOINC 'janitor' also needs to be created to clean up whatever mess have been created (or dumped) at the WCG-servers by the client's BOINC, the WCG servers or from any external-to-WCG processes that messes up WCG's BOINC server. The two janitors are to be tasked to coordinate their clean up efforts. As in real -life, janitor processes also play a role in augmenting security. That thing that looks like a thrash, or a mess, may well be a virus.

P.S.
I also have a BOINC mess. I have four HCC_7.08-GPU-WUs that remain stuck with a Uploading status for days now. No amount of hitting the Update button or any sync with the WCG-servers would remove that mess. A BOINC janitor-process should be able to clean up that and other future BOINC mess.
;
; andzgridPost#801
;