Folding Forum

Hi. Obviously I don't want to contribute to overloading the servers with constant pings, but when FAH runs out of Work Units to download, I do notice that the next attempt gets progressively longer with each failed attempt, getting up to 4 hours after I've gone to sleep. Sure, a simple closing of the app and restart will reset the cycle and usually start downloading a new WU, but is there a way to lock the top end of these times to something more reasonable, like 10-30 minutes?

AFAIK, no. The system is designed to progressively back off when F@H is overloaded, in the hope that the servers can catch up. Retrying more often can make things worse, but it is worth doing a pause/restart before bed time if the delay is already more than say 15 minutes.

My delay is well into many hours now :/

Seems like the client continues to lengthen the delay on every failure. Wouldn't it be better for it to have a maximum cap for the delay time so it doesn't continue getting longer and longer into many hours?

Pausing the client for a minute and then starting folding will reset the timer.

Mace68 wrote:Seems like the client continues to lengthen the delay on every failure. Wouldn't it be better for it to have a maximum cap for the delay time so it doesn't continue getting longer and longer into many hours?

It is always difficult to design a strategy for retries that is right in all circumstances. The F@H algorithm for retries is designed to prevent overloads when servers come back into service after an outage. It may not be ideal in the current circumstances, but we must work with what we have. I'm sure the team are learning from the experience -- expect a more robust F@H environment in the future, but big changes won't happen while the Coronavirus workload is being processed unless they offer safe path to a large benefit in getting work done.

The delay makes sense. Obviously you don't want everyone checking for a new WU every 10 seconds, but is there a reason behind the exponential increase up to several hours of delay? Is there a reason a 30min cap on the delay until the next attempt would not be reasonable? The recent increase in available computing power has outpaced the creation of new WUs, so there is lots of down time waiting for more WUs. When a new batch of WUs comes out there are undoubtedly thousands of clients with hours until they check for a new WU, which is thousands of hours of unused compute time. This surge in new users likely won't last very long, but that doesn't mean the client shouldn't be adjusted to distribute WUs more efficiently.

vica153 wrote:The delay makes sense. Obviously you don't want everyone checking for a new WU every 10 seconds, but is there a reason behind the exponential increase up to several hours of delay? Is there a reason a 30min cap on the delay until the next attempt would not be reasonable? The recent increase in available computing power has outpaced the creation of new WUs, so there is lots of down time waiting for more WUs. When a new batch of WUs comes out there are undoubtedly thousands of clients with hours until they check for a new WU, which is thousands of hours of unused compute time. This surge in new users likely won't last very long, but that doesn't mean the client shouldn't be adjusted to distribute WUs more efficiently.

The word from the team is that the current client is effectively EOL and will receive no more updates. It is said that the developers are working on a new open-source client (good!), but in the meantime they are either unwilling or unable to make changes to the current one.

A cap on the delay would make sense if the problem was the supply of WUs. In fact the problem is not work availability but server capacity, so capping the retry time will make things worse. The algorithm is designed to cope with server downtime, where the increasing uncapped delay is necessary to avoid swamping the server when it returns to duty.

You don't have access to the statistics and neither do I so we'll just have to settle for a SWAG. At any specivie time since COVAID19 came on the scene, estiamte how many FAH clients are actively processing a WU that they have already downloade (and they're not bothering the server). Now estimate how many of those WUs will finish within the next minute{?} plus how many newly insstalled clients will come on-line during that same minute. With all of our servers operating at or close to their bandwidth limits, how many more servers would we require to serivce all those clients trying to get work during that minute. Ok, now add in all those additional clients which have been trying for a while and for which the retry interval has just expired. At what value should the exponential retry interval be capped so that everybody gets what they want? ... and how much would that improve the chances that FAH will discover a cure within K weeks?