@TPCBF ,

Thanks, because one could not have been without the other [tell the complete story helps understanding] ;)

The remedy that has been mentioned a few times on the forums [other members] is, to actually do what you don't... up the buffer. Set it "connect about every..." above 24 hours / 1 day, and one or the other criteria will force a connect... the RtR older than 24 hours condition being one of them. Fetches and reports are combined whenever the scheduler can. Then you can 24/7 do WCG without having to worry, but then, you might have other reasons keeping a low cache most of the time.

Not seen or heard of anyone incurring this with the 7.0.42 [test] client many have already adopted because of the easy GPU control app_config.xml feature... this version is very good at fetching work minutes before the current work ends when running on empty, even with zero buffer setting. Hopeful that 7.0.44 will finally make it to "recommended" at Berkeley, which does not mean WCG will. They're still testing and as has been usual, there almost surely coming a special WCG skinned version, which will also likely get a formal Beta through the WCG network [announcement on forums].

@Andz,

Please do *not* dilute/hijack this thread further with Upload issues and whatnot, already discussed in other current threads. This one is about Ready to Report not going by themselves and the search for the reasons. Uploading result files is a wholly different matter. As for your janitor story, yet again I have to refer you to the developers and their alpha mail list. There's the place to discuss your "how BOINC should/could function better". We're trying to help crunchers forward here with what's available.... support forums these are. Since I don't understand 90% of what you're on about [frankly given up and skipping forward], wont be couriering it for you. "Dovetailing"... use sane layman language and not some carpenters technique as metaphor, probably 99% or more of the regular members would not know what it would be... to add, that a large portion of the members don't have English as their native tongue, so please.

Hi mushahi,

Glad things normalized. Yes, BOINC will be quirky at times, it's AI instilled in a way, supposed to learn from the crunching behavior / schedule of the weeks before, so it does take time. Make a change to the prefs, intervene by hitting update, and it's possible to take another few weeks to balance.

Will almost guarantee that a buffer setting of > 1 day ensures automatic and rather regular reporting, but only if you leave "Maximum additional work buffer" (fka Additional buffer") zero. I've written up a long draft FAQ back when the first client 7 came along to expand on the use of old v6 and new v7 ways of buffering. That impacts when RtR's get cleared. Not reporting and not having work at all, cores idle... personally never seen it. The client is coded to fetch work when cores go idle, either from the main project or from other "backup" projects.

It was TPBCF up in this thread reporting on no RtR clearing, AND no work being fetched.

Oh, and the latest on when RtR's report is found in this FAQ:
and the 13 conditions when they will go by themselves: http://boincfaq.mundayweb.com/index.php?view=68

Nr.12 is me starting the suggestion at the developers alpha mail list for the network condition to which the CPU side was added in one slick flow for consistency. It ensures that if you only do part day networking, BOINC will clear all RtR before the crunching stops or network is suspended. My clients stop networking from about pre-shuteye to 10 AM, but even if you set a time of e.g. 22:15 to 22:00 (which in effect is 15 minutes network interruption), will the time from 21:30 to 22:00 clear all RtR immediately... sort of a no later than 24 hours enforcement. If this gives anyone any ideas of "what if I would...", than I'm going to leave that to your creativity and me to the left unsaid. :D