https://secure.worldcommunitygrid.org/forums/wcg/viewthread_thread,28397

Yeah, I got bitten by the same thing. Even worse, my most productive machine "BEAST" is in its little room in the basement and only gets looked at occasionally using remote desktop. When I looked it was saying that all the tasks had been done, none were running, and that communications were deferred for 6+ hours. The latter seems to be a truly dumb thing to write into a program. Maybe defer for 10 minutes or for some short random period but six hours is entirely too much. BEAST can chew through 8-10 work units in that time. My two other fast machines were at least not stuck with 6 hours -- just 3 which is at least better.

I did jack up my queue of spare work units to allow a bit of work to get done in the future if things go wonky again. 1 day now. Maybe it should be longer than that though.

Maybe some mechanism needs to be added to have the clients notify us by email if things like this go wrong. Should be doable -- other programs manage it.

What client version? The deferrals are incremental so if there was a curve-ball, 6 hours is possible, where when the server contact proofed to be impossible.

The price to the grid was dear. Tuesday morning was 115 years instead of ~est.155 years with already an est. shortfall for Monday of 25 years (the fail started on Monday). The afternoon session came back to 142 another 12-13 short, so in all 78+ years gone, irredeemably. So with better logic in the upcoming client and bits like zero weight backup project function to prevent a client going truly idle, it's up to the techs and the developers to see how what else needs tweaking. Certainly if projects have hundreds of thousands of devices active and coming back up, you'd not want them all connect within the hour of coming online again... that would cause another crash for sure.

edit: many of the deferred contacts reported in on Wednesday morning turning in an extra 22 CPU years over last weeks same day morning session, 178 now versus 156 last. Maybe there's another little kick this afternoon from those that had been running on cache.

Since my client is attached to the internet 24/7, I've set the connect interval to 0.00 days. When I looked in about 8 hours into the crash the deferral counter was at 31 minutes, but that's with the 6.10.29 alpha client. As WCG is preparing and testing 6.10, I've asked to look into the logic to see if that needs further tweaking. It may be different, improved over the present 6.2 client that is still the house standard download. Can't find ready digestible documentation that explains the deferral states, how far they increment and so on. In past seen it was going over 24 hours if a project continued to be down / unreachable.

If you wish to make sure to be able to bridge downtimes set it back to the default 0.3 days additional buffer (local prefs) or cache on the web device profile. Think many run with 0.5 to 1.00 days and more looking at the wingmen validations. 1.00 is also the longest period that the client will try to send the Ready to Report jobs, where the result files are always uploaded ASAP if there is a ready connection.