I set my cache for 0.1 days.
I can't remember a time when I've run out of work.
There is that check box to also prevent such a thing...you know what box.

I'd go along with Sgt. Joe on this, and I've reset my cache to 5 days.

If a 10-day cache "near guarantees" late-reports, then this indicates that the job run-time is being consistently underestimated. With such a large cache, the long jobs should cancel the short.

Certainly, manual cancellation simply delays the WU completion overall. I found I was cancelling a few jobs once a month or so, and reducing the cache should make that unnecessary.

Again, we should be careful not to generalise too much. Since I'm unemployed, I have plenty of time to monitor progress and compensate - gives me something to do. An unattended installation will be different no doubt.

As for "How often do these floods/rains/snow/fires ISP collapses occur on your end and what has been their max days calamitous duration?"

Er, well, floods aren't a problem here for me. Gets a bit hard even for Mother Nature to flood the Indian Ocean - and we'd have a few more urgent problems than WCG runtimes if that occurred.

Rain? That's another matter. The first rains of winter tend to wash out the dust accumulated on the insulators over Summer. Normally leads to a short power-outage, sometimes hours but can be a day or more. Power is more often interrupted by the latest speeding clown wrapping themselves around a power pole though. That has been known to happen every Saturday night sometimes for weeks on end.

Snow? Snow within 1000Km would be all over the news. More of a problem in Canadia and Russia and Northern Europe, I hear. Did have a bit of a hailstorm a few days ago though. Didn't affect me, but some places not too far away were blacked out for a couple of days. Same places were affected similarly by fires a few months back. Not as bad as the Victorian fires last year which coincided with the Queensland floods - and there have been more floods in the East this year. Priority for some reason is to get the people and animals safe first, then make sure they're supplied with beer and food. Inexplicably, restoring internets is further down on the list...

I've never understood this behavior in BOINC. I don't see the point in this 2-step activity to report a completed WU (Finish WU -> Ready to Report -> Sent).

Mysteron347 wrote snip
With HFCC/FAAH/HCMD2/DDDT2 is near impossible to get exact estimates... remember most we calculate is non-deterministic. Statistically one would expect long and short to cancel out, but the controls work on the current series of work to guesstimate the TTC of the rest so if there's a short series of HCMD2 grand children that came with a 4.5 hour estimate [project running average] and they take just 1-3 hours, the backfill is affected. Then when the parents come in again with 6-12 hours run time... panic and that changes client behavior for longer and we see posts about "Why is my client not getting work?"

Not going to expand on this: All forums frequenters have seen many discussions on Duration Correction Factor (DCF) blow outs on client side due the variability. I'm reading of future developments (following the developers check-in list and saw a few cheers by knreed elsewhere) that will further mitigate, but that will be next year earliest.

yes that is the bigest problem with this job is the inability to judge ahead of time how big a work unit should be. if at all posible keep your machine connected at all times and a very small catch and that should keep you crunchig well. if you cant then you cant.

honestly if a work unit dosnt get returned then it dosnt get returned and someone else will crunch it.

i cant remember what project it was but at one time i had over 8 pages of Pending Validations with just 4 cpu cores total running.

back when there were RICE units to crunch it was easy to figure out how many you needed cause they were basicaly a set time.

crunch and be happy... and go for the next level of badge