Download Bug Happening Again (*.220)

[Michigeezer]

I am shutting off my folding for now. I don't need the hassle of checking the system and having to "restart" the folding 2 or 3 times a day. I will check back every week or so to see if the server is fixed or the people at Temple have been replaced with somebody having the competence to determine and fix the problem which has existed for way too long.

[wdanwatts]

Under Linux

Code: Select all

iptables -I INPUT -s 155.247.166.220 -j DROP

works, but I don't know if it survives a reboot.

[Sn0wy23]

The last time this was a major issue, there was some sort of networking problem that somehow corrupted peoples routers. The cure was to reboot ones router. I wonder if this is worth trying again for those having serious problems this time round?

rebooting a router may be similar in impact to a TCP connection as rebooting the client

I have tried reboot my router but have same issue. Initially it was working ok, getting WUs from alternate IP, but after a few days my PPD fell massivly as I was being given very low point projects that took longer than they should have done. I have unblocked the IP but don't get the failed to connect to IP, the IP just doesnt come up in my clients currently. Hopefully the server admin have it sorted and it will quietly come back online.

[HaloJones]

Under Linux

Code: Select all

iptables -I INPUT -s 155.247.166.220 -j DROP

works, but I don't know if it survives a reboot.

sorry but works how? prevents connection attempts? prevents connection failures?

[b-morgan]

Under Linux

Code: Select all

iptables -I INPUT -s 155.247.166.220 -j DROP

sorry but works how? prevents connection attempts? prevents connection failures?

As written, this rule drops all packets coming from that IP address, i.e. it will cause a connection failure in the FAHClient. See this post for the log output when a similar command is in force.

[bruce]

When a server doesn't respond, the client should ask for a different work server.

[bruce]

I then on a wild hunch changed them all to client-type=beta and they've all been fine since.

That is interesting. I have 7 out of 9 machines set to client-type=advanced, which may explain why no problems (if someone can figure out how it explains it).

Each work server maintains a list of projects it can distribute. Your client provides a list of criteria for your next assignment (including client-type). FAHClient then asks an Assignment Server to find a Work Server that can supply your client with a new WU matching your requirments and you are assigned to that WS. The WS initiates a download.

If you change your client-type setting, the AS will modify it's search pattern accordingly.

It's not easy to determine which WS happens to be supplying WUs of a particular client-type (that characteristic may change without notice), but the AS knows which list(s) to look on and may decide to assign you to a different WS.

[wdanwatts]

The 'iptables' command works this way:

Code: Select all

21:54:03:WU02:FS00:Connecting to 65.254.110.245:8080
21:54:03:WU02:FS00:Assigned to work server 155.247.166.220
21:54:03:WU02:FS00:Requesting new work unit for slot 00: RUNNING gpu:0:TU116 [GeForce GTX 1660] from 155.247.166.220
21:54:03:WU02:FS00:Connecting to 155.247.166.220:8080
...
21:56:15:WARNING:WU02:FS00:WorkServer connection failed on port 8080 trying 80
21:56:15:WU02:FS00:Connecting to 155.247.166.220:80
21:58:26:ERROR:WU02:FS00:Exception: Failed to connect to 155.247.166.220:80: Connection timed out
21:58:27:WU02:FS00:Connecting to 65.254.110.245:8080
21:58:27:WU02:FS00:Assigned to work server 140.163.4.241
21:58:27:WU02:FS00:Requesting new work unit for slot 00: READY gpu:0:TU116 [GeForce GTX 1660] from 140.163.4.241
21:58:27:WU02:FS00:Connecting to 140.163.4.241:8080
21:58:27:WU02:FS00:Downloading 11.66MiB
21:58:30:WU02:FS00:Download complete

[cafromaa]

I have been running multiple folding computers for many years. For the last couple of years I have had the problem of Work Queue slots getting stuck in Download. My fix has always been to restart the impacted computer and everything clears up. Surprisingly, about a month ago the failures stopped so I have been rejoicing that whatever the problem, it was finally fixed.

This morning I have 2 Work Queues stuck and a system reboot did not help. One slot is using Work Server 155.247.166.220 Collection Server 0.0.0.0 and says Waiting on WS Assignment. The other slot has both servers 0.0.0.0.

Since the system restart did not fix the Work Queue Download stick this time it seems like a new problem. Any idea on the cause of this one and what I can do to recover? I have gotten used to the more robust Work Queue performance and am dreading a new round of problems.
*
*
Update: Work Queue just started working. Now Work Server is 140.163.4.241 Collection Server 128.252.203.4 for both previously hung slots. Hopefully just a one time thing and we are back to the performance of the last month.

[toTOW]

We are quite low on work with A7 core (CPU) and 21 core (GPU) ... I think that's what you saw.

[bruce]

This problem has also been associated with heavy server traffic, which we've made servers changes that explain your earlier remarks.

A couple of new servers have arrived and are currently being configured so we expect a sound solution in the very near future.

(The COVAID19 rush didn't help, either.)

[kwerboom]

This problem has also been associated with heavy server traffic, which we've made servers changes that explain your earlier remarks.

A couple of new servers have arrived and are currently being configured so we expect a sound solution in the very near future.

(The COVAID19 rush didn't help, either.)

I've been trying to follow along on this forum thread about this problem. I've asked before if the problem with server 155.247.166.220 has been fixed and it seemed at the time that it hadn't. Can I assume safely from this last post that the problem has now been solved by the new servers so that I can remove the IP block on 155.247.166.220?

[snapshot]

As it bit me again at around 09:00 GMT today I think we can reasonably assume it isn't fixed yet.

[kwerboom]

As it bit me again at around 09:00 GMT today I think we can reasonably assume it isn't fixed yet.

Well that's sad to hear.

[toTOW]

A new server (155.247.164.213) has been started at Temple University. Does it helps ?