Folding Forum

Same problem reported here: Subject: Multiple WU's Fail downld/sending to 155.247.166.* has not yet been permanently cured.

I'll reboot my router now before settling down for the night to see if that helps.

Under Windows, update host file to redirect 155.247.166.219 to 155.247.166.220 ( for exemple ) can work ?

I wouldn't recommend it.

I don't know if the congestion accumulates at the campus router or at one of those two servers (or both).

The choices of CSs are established when the WS code is started. From time-to-time some choices fall off the list and from time-to-time new connections are established. It's a dynamic list. Go to https://apps.foldingathome.org/serverstats and to a fly-over on the "YES" in the CS column. Right now, it says that there are two active CSs: 155.247.166.220 and 128.252.203.2, This list is likely to change.

If the congestion is at the campus router, *.220 will be no better than *.119 and uploading to *.2 is probably better. If the problem is in your FAHClient's connections, nothing will help except restarting FAHClient. In either case, if something happens to your route to *.2, you'll have blocked any possible connection directly to *.119. Bottom line: The net-admins are probably the only people who can do anything worthwhile until the FAHClient code is updated.

FWIW rebooting my router has meant that my clients have been trouble free last night and today.

.219 seems to be working better now

.219 is in problem again

So is .220.

.220 is ok

01:30:11:WU00:FS01:Connecting to 155.247.166.220:8080
01:30:12:WU00:FS01:Downloading 15.58MiB
01:30:16:WU00:FS01:Download complete

Maybe you can just pause and unpause?

Has there been any permanent fix for this issue? Ever since before this thread was started it comes and goes intermittently. I have a proposed solution if you are interested. Could checks be built into future client releases that when a WU reaches 75% initiate a download, and then again for each consequent 5% mark to check if a new WU has already been downloaded and if not initiate?

cheechi wrote:Has there been any permanent fix for this issue? Ever since before this thread was started it comes and goes intermittently. I have a proposed solution if you are interested. Could checks be built into future client releases that when a WU reaches 75% initiate a download, and then again for each consequent 5% mark to check if a new WU has already been downloaded and if not initiate?

The client is already set to download a new WU at 99% by default, that can be set to a value between 90 and 100%.

There is code in the client to detect a download that has failed. There is a known issue where a download or upload stops progressing and the client does not detect that happening. Changes to the client over the last few versions have improved that, more often the client will detect that a transfer has stalled and retry it within 15-30 minutes. But it still sometimes doesn't.

As for thresholds on detecting such a problem, that can be tricky. I have monitored slow transfers in the past, sometimes they have trickled down to just a few hundred bytes a minute, then eventually went back to normal many minutes later. Which is better in that situation, to retry and have to transfer the whole WU over again, or to keep on going?

I agree with everything you say in theory, and mostly in practice. Would it be tricky to cat files in the work folder to verify if there is one yet to be worked and if not to re-initiate the download? Or either to give the user configuration of the 15-30 min retry period you describe? This could solve both the problem of potentially abandoned download due to slow or intermittent connectivity as well as the client's difficulty with curl (or whatever it uses).

I'm not trying to give you a hard time, just that my idle GPUs are so very lonely.

A significant amount of work has been applied to a revised client. I don't have any details about what, if any, enhancements have been applied for this issue. Getting a new client ready to beta test is not an insignificant effort, especially when there are interruptions. FAH's budget for development is rather small. (government research grants are highly restricted to RESEARCH, not "incidental" programming activities)

I understand and appreciate the replies. Thank you for tolerating my frustration.