Folding Forum

Server does not seem to be giving out any work

codysluder wrote:(Got status 503) means that the server is too busy for you to connect. There's nothing that anyone can do except to tell you to come back later. The client will do that automatically, so just let it do it's thing.

lanbrown wrote:I know that, but when it is like that for nearly a week, there is an issue; a BIG issue. If a server is like that for over two-days (including weekends when the load should be less), then it needs to be acknowledged.

EvilAlchemist wrote:Server does not seem to be giving out any work

Just so it's clear, if a server is too busy to accept all the uploads that are hitting it at any one time, it's still accepting a certain percentage of the uploads. The real "fix" for a problem like that is to stop (or slow) distributing work which needs to be returned to that server to give the server more time to catch up with the uploads. In other words, it HAS BEEN fixed, insofar as possible.

There's nothing that anyone can do about the WUs which have already been distributed except to wait for the server to accept that backlog, and depending on how many WUs have already been distributed, it can take some time to catch up. In other words, Codysluder is correct and none of us (including lanbrown, myself, and any number of other people) will just have to wait an unknown amount of time.

171.64.65.111 is in "reject" mode and not accepting any uploads.

171.64.65.111 classic vspg5v2 vvoelz full Reject 2.26 0 0 14 23836 1217 5 5.81 14824 292 135418

[15:03:46] - Couldn't send HTTP request to server
[15:03:46] + Could not connect to Work Server (results)
[15:03:46] (171.64.65.111:8080)
[15:03:46] - Error: Could not transmit unit 09 (completed December 18) to work server.
[15:03:46] - Read packet limit of 540015616... Set to 524286976.

[15:03:46] - Couldn't send HTTP request to server
[15:03:46] + Could not connect to Work Server (results)
[15:03:46] (171.67.108.17:8080)
[15:03:46] Could not transmit unit 09 to Collection server; keeping in queue.

I had it with that server and use a NAT rule that changes the destination to a different server. This will prevent any future assignments to those servers and will go to a server that can actually assign and accept. Had to make some DNS changes as well.

And your progress so far is?

After reading this half december I thought the problem I saw with 171.64.65.111 / 171.67.108.17 would resolve itself in a matter of days. But I still see that the status is "F@H: Attempting to send results" and the logging shows:

[16:36:28] + Attempting to send results
[16:36:59] Couldn't send HTTP request to server (wininet)
[16:36:59] + Could not connect to Work Server (results)
[16:36:59] (171.64.65.111:8080)
[16:36:59] - Error: Could not transmit unit 00 (completed December 20) to work server.


[16:36:59] + Attempting to send results
[16:37:00] Error: Got status code 503 from server
[16:37:00] + Could not connect to Work Server (results)
[16:37:00] (171.67.108.17:8080)
[16:37:00] Could not transmit unit 00 to Collection server; keeping in queue.


[16:37:00] + Attempting to send results
[16:37:32] Couldn't send HTTP request to server (wininet)
[16:37:32] + Could not connect to Work Server (results)
[16:37:32] (171.64.65.111:8080)
[16:37:32] - Error: Could not transmit unit 00 (completed December 20) to work server.


[16:37:32] + Attempting to send results
[16:37:33] Error: Got status code 503 from server
[16:37:33] + Could not connect to Work Server (results)
[16:37:33] (171.67.108.17:8080)
[16:37:33] Could not transmit unit 00 to Collection server; keeping in queue.

But according to the server-page the server is accepting, thus I would assume that in 3 weeks the results of the 20th should have been uploaded by now.
Is there a way to resolve this in another way, or is waiting until the server accepts your results the only solution?

And isn't there a way to get less load on this server?

Error 503 is the server's way of keeping the load from getting too high. It simply refuses to handle more simultaneous requests than it can handle.

The new servers that they have been talking about is a way of dealing with it, too. Those new servers take time to be installed/configured but in time, the total FAH work will either be on faster servers or spread across more servers.

Since Mid-December is a long time, is it possible that you're getting an error 503 from some other server between you and Stanford? It's possible (though unlikely) that a router somewhere has been overloaded, too.

Has your client been running continuously and have other WUs been uploaded successfully to other servers?

You are in "good company" though. There are a number of other reports of problems with this server, so there's probably nothing you can do.

I also see the wininet error that was typical with a bad setting in old v5 clients ... if you're using this old client, make sure you disabled the "use IE setting" option.

bruce wrote:Since Mid-December is a long time, is it possible that you're getting an error 503 from some other server between you and Stanford? It's possible (though unlikely) that a router somewhere has been overloaded, too.

Has your client been running continuously and have other WUs been uploaded successfully to other servers?

On this particular (multi-core) computer I run continuously with 2 clients (one GUI-client (the one with these problems) and one command-line client (but that one works fine)). In the period I only restarted the computer once. At startup the GUI-client starts automatically. But it sometimes crashes after a while, which results in a Visual studio request if I want to start debugging it (therefore I notice it) and thus I manually restart the GUI-client. This happened also 1 or 2x in this period (and both times I restarted the GUI-client).
Thus most of the time the client was online and capable of sending the results.

According to the logfile other WUs (which started before and after the one giving the problems) were uploaded without problems.
Also my other computer (with 2 command-line clients) and my PS3 don't show this problem (and all are sharing the same router to connect to my ISP). That is why I suspected the WU-server.

bruce wrote:You are in "good company" though. There are a number of other reports of problems with this server, so there's probably nothing you can do.

That is why I waited that long before I posted here. It has happened before that a server was down and I had to wait 1 or 2 days before the results were uploaded.

toTOW wrote:I also see the wininet error that was typical with a bad setting in old v5 clients ... if you're using this old client, make sure you disabled the "use IE setting" option.

/*quick-check */ The GUI-client is a v5-client (5.03) and it *had* "use IE setting" enabled. Although, as I replied to bruce a few lines back, other WUs were uploaded correctly and I never had this problem before. (The only problem I get is that the GUI-client sometimes (once a month) crashes and than I have to restart it by hand).
But it is now disabled. Let's hope that that resolved the problem.

BTW. The only reason that I still have this GUI-client is that I'm too lazy to uninstall it and replace it with a command-line version, since most of the time it is working correctly. (As you can see I'm not that great a fan anymore of the GUI-client, since it is the only client with which I have had problems. Note: The command-line client I use on this computer is also a V5 (5.04) client)

@Nemelis if you install the v6 clients you give your client a greater chance of getting work... some of the cores require features of the v6 client to work and are therefore only assigned to such clients. (I know getting work isn't the problem, just pointing this out)

Credit goes to toTOW for noting the "Use IE Settings" option.

That option has been removed from V6 because it caused many problems just like the one you're reporting. In fact, the WU was probably uploaded long ago but when "Use IE Settings" is enable, the client never receives the acknowledgement from the server so it incorrectly assumes the WU was not uploaded. This results in a WU being uploaded many, many times but the first one got credit and subsequent uploads are rejected as duplicates. (From the messages that you see from the client, the WU was never uploaded.)

So... I already had completed 2 Work Units on PS3. Now i installed F@H on my Computer too.
Today i finished my first Work unit...
When i wanted to see my stats, i couldnt believe my eyes!! I only have folded 2 Work Units...
I didnt get my folded work unit and my points...
What can i do?
Here is the Log:

I have the same problem...
and I dont want to fold the units again... it took so much time...

Daniel0108 wrote:So... I already had completed 2 Work Units on PS3. Now i installed F@H on my Computer too.
Today i finished my first Work unit...
When i wanted to see my stats, i couldnt believe my eyes!! I only have folded 2 Work Units...
I didnt get my folded work unit and my points...
What can i do?
Here is the Log:

Code: Select all

[08:26:15] + Attempting to send results [January 10 08:26:15 UTC]
[08:26:16] - Couldn't send HTTP request to server
[08:26:16] + Could not connect to Work Server (results)
[08:26:16]     (171.64.65.111:8080)
[08:26:16] + Retrying using alternative port
[08:26:16] - Couldn't send HTTP request to server
[08:26:16] + Could not connect to Work Server (results)
[08:26:16]     (171.64.65.111:80)
[08:26:16] - Error: Could not transmit unit 01 (completed January 10) to work server.
[08:26:16]   Keeping unit 01 in queue.
[08:26:16] Project: 6313 (Run 448, Clone 22, Gen 2)


[08:26:16] + Attempting to send results [January 10 08:26:16 UTC]
[08:26:17] - Couldn't send HTTP request to server
[08:26:17]   (Got status 503)
[08:26:17] + Could not connect to Work Server (results)
[08:26:17]     (171.64.65.111:8080)
[08:26:17] + Retrying using alternative port
[08:26:58] + Results successfully sent
[08:26:58] Thank you for your contribution to Folding@Home.
[08:26:58] + Starting local stats count at 1
[08:26:59] - Preparing to get new work unit...
[08:26:59] + Attempting to get work packet
[08:26:59] - Connecting to assignment server
[08:27:00] - Successful: assigned to (171.64.65.111).
[08:27:00] + News From Folding@Home: Welcome to Folding@Home
[08:27:00] Loaded queue successfully.
[08:27:07] + Closed connections

The stats pages do not update in realtime, The stats are only updated every couple of hours on the stanford site and 3 hours on the 3rd party sites. Check back later on today and you should see a credit for your WU, also bear in mind if the stats server is heavily loaded it may take longer to show up
The cannot connect to work server message will pop up occasionally, the client will automatically keep trying to transmit the results, only flag up a problem if you have been trying for a couple of hours - then we'll help you trouble shoot

bruce wrote:That option has been removed from V6 because it caused many problems just like the one you're reporting. In fact, the WU was probably uploaded long ago but when "Use IE Settings" is enable, the client never receives the acknowledgement from the server so it incorrectly assumes the WU was not uploaded. This results in a WU being uploaded many, many times but the first one got credit and subsequent uploads are rejected as duplicates. (From the messages that you see from the client, the WU was never uploaded.)

Hi!

Thanks for the explanation. It makes sense. However, I'm running a V6 client (uniprocessor 6.23 Windows) and still have those symptoms (i.e. WU has been uploaded and credit has been given, but WU still is in queue and still uploads are tried by client). So I guess there's still a problem even without the "Use IE Settings" option.

A parallel issue at this time is the collection servers give 503 errors, even in the web browser (here more verbose without the error code). But since I already have the credit for this single problematic WU and everything else is running fine right now, I just wait and drink some tea (another phrase for "wait and see" here in Germany).

Gerby