171.64.122.139

[hisui]

having problem with that server again.get 400 error code

[DrBB1]

Had the problem again. Took Jimbo's advice--it worked!

Thanks!

[cardnyl]

Still getting a ton of the following from at least 3 different workstations. I have tried every combination of work unit size and advanced methods flags possible as well as upping the ram limit to 1gb for the client without success. I don't suppose there's some switch I can use at the command line to manually specify a working server is there?

Code: Select all

[19:38:33] - Autosending finished units...
[19:38:33] Trying to send all finished work units
[19:38:33] + No unsent completed units remaining.
[19:38:33] - Autosend completed
[19:38:33] - Preparing to get new work unit...
[19:38:33] + Attempting to get work packet
[19:38:33] - Will indicate memory of 800 MB
[19:38:33] - Detect CPU. Vendor: GenuineIntel, Family: 15, Model: 6, Stepping: 5
[19:38:33] - Connecting to assignment server
[19:38:33] Connecting to http://assign.stanford.edu:8080/
[19:38:34] Posted data.
[19:38:34] Initial: 40AB; - Successful: assigned to (171.64.122.139).
[19:38:34] + News From Folding@Home: Welcome to Folding@Home
[19:38:34] Loaded queue successfully.
[19:38:34] Connecting to http://171.64.122.139:8080/
[19:38:34] - Couldn't send HTTP request to server
[19:38:34] + Could not connect to Work Server
[19:38:34] - Attempt #1  to get work failed, and no other work to do.
             Waiting before retry.

[bruce]

I don't suppose there's some switch I can use at the command line to manually specify a working server is there?

No. The Pande Group assigns various work server based on scientific need. In this case, server 171.64.122.139 has an exceptionally high net load, but it's successfully distributing a lot of WUs. The real question is what other servers happen to currently have WUs that fit the requirements of your client, but that's not an easy thing to determine.

Here's another current report of the same problem viewtopic.php?p=95465#p95465

I'll be sure the Pande Group notices your report.

How long have you waited before a WU was assigned?

[hisui]

already waited for a day and still get the same error message like this
[00:18:26] + Attempting to get work packet
[00:18:26] - Connecting to assignment server
[00:18:26] - Successful: assigned to (171.64.122.139).
[00:18:26] + News From Folding@Home: Welcome to Folding@Home
[00:18:27] Loaded queue successfully.
[00:23:27] Couldn't send HTTP request to server (wininet)
[00:23:27] + Could not connect to Work Server
[00:23:27] - Error: Attempt #9 to get work failed, and no other work to do.
Waiting before retry.

[cardnyl]

I don't suppose there's some switch I can use at the command line to manually specify a working server is there?

No. The Pande Group assigns various work server based on scientific need. In this case, server 171.64.122.139 has an exceptionally high net load, but it's successfully distributing a lot of WUs. The real question is what other servers happen to currently have WUs that fit the requirements of your client, but that's not an easy thing to determine.

Here's another current report of the same problem viewtopic.php?p=95465#p95465

I'll be sure the Pande Group notices your report.

How long have you waited before a WU was assigned?

hey bruce,

I am not currently near my farm so I can't get you a precise timestamp per say but offhand I do remember 1 client get to its 56th retry and another to 38th. The third client I can't recall offhand. It wasn't substantially high since it finished its previous work unit only recently, <20 if I had to guess at random.

[bruce]

I am not currently near my farm so I can't get you a precise timestamp per say but offhand I do remember 1 client get to its 56th retry and another to 38th. The third client I can't recall offhand. It wasn't substantially high since it finished its previous work unit only recently, <20 if I had to guess at random.

Close enough. Thanks.

[toTOW]

On my machines, -advmethods is still a good workaround to avoid being assigned to this server (it will often send the client to 169.230.26.30 and its small Amber WUs).

[cardnyl]

Hey bruce and toTOW,

Came in this morning and had 6 of my uniprocessor clients waiting for work. I can provide snippets of the FAH logs but they all look identical to the one I posted before. 2 of the clients were windows, the other 4 were Linux. The advanced methods work around managed to get me work for both of the windows clients (instantly from 169.230.26.30) but not the Linux clients (that still try to connect to the server in question) which seems a bit strange. I double checked all of the afflicted Linux clients client.cfg files as well as manually running the binary using -advmethods from the command line with no luck.

Another one of my windows uniprocessor clients will finish its work tonight and I am pretty sure advanced methods is turned off. I'm not sure if it will help determine why exactly the windows clients picked up work instantly while the linux clients did not but here are the respective specs and settings for all of the machines:

OS Memory Available Processor
Windows 1.5GB P4 2.8 (non-HT)
Windows 400mb P4 3.2 HT
Linux (1) 500mb P4 D 925 3.0ghz
Linux (1) 500mb P4 D 925 3.0ghz
Linux 500mb P4 3.0 (non-HT)
Linux 500mb P4 D 925 3.0ghz

(1) Same physical processor, different core.

If you can think of anything else I could try let me know.

[HardToThrill]

I have clients that have been waiting more than 12 hours for WU:

Code: Select all

[02:19:53] - Preparing to get new work unit...
[02:19:53] + Attempting to get work packet
[02:19:53] - Connecting to assignment server
[02:19:54] - Successful: assigned to (171.64.122.139).
[02:19:54] + News From Folding@Home: Welcome to Folding@Home
[02:19:54] Loaded queue successfully.
[02:19:54] - Couldn't send HTTP request to server
[02:19:54] + Could not connect to Work Server
[02:19:54] - Error: Attempt #1  to get work failed, and no other work to do.
             Waiting before retry.


[Note: same error continues through 24 attempts]



[12:35:44] - Error: Attempt #22  to get work failed, and no other work to do.
             Waiting before retry.
[13:23:59] + Attempting to get work packet
[13:23:59] - Connecting to assignment server
[13:23:59] - Successful: assigned to (171.64.122.139).
[13:23:59] + News From Folding@Home: Welcome to Folding@Home
[13:23:59] Loaded queue successfully.
[13:24:00] - Couldn't send HTTP request to server
[13:24:00] + Could not connect to Work Server
[13:24:00] - Error: Attempt #23  to get work failed, and no other work to do.
             Waiting before retry.
[14:12:00] + Attempting to get work packet
[14:12:00] - Connecting to assignment server
[14:12:01] - Successful: assigned to (171.64.122.139).
[14:12:01] + News From Folding@Home: Welcome to Folding@Home
[14:12:01] Loaded queue successfully.
[14:12:01] - Couldn't send HTTP request to server
[14:12:01] + Could not connect to Work Server
[14:12:01] - Error: Attempt #24  to get work failed, and no other work to do.
             Waiting before retry.

[bollix47]

I have clients that have been waiting more than 12 hours for WU:

There's a problem with that server:


viewtopic.php?f=18&t=7756&start=45
EDIT my Mod: These posts have now been moved to the discussion you referenced. See my reply below (next page).
-Bruce

[HardToThrill]

one of my clients is on it's 25th attempt (& 12+ hours no WU) - same log report as others

[Mactin]

No. The Pande Group assigns various work server based on scientific need. In this case, server 171.64.122.139 has an exceptionally high net load, but it's successfully distributing a lot of WUs. The real question is what other servers happen to currently have WUs that fit the requirements of your client, but that's not an easy thing to determine.

Same problem here

None of my uniprocessor machines have received a wu from 171.64.122.139, with "hundreds" of tries, since friday PM, some have been days without WUs. Here and there I get a WU from another server. I have switched a few to -advmethods and getting p46xx.

If 171.64.122.139 is successfully distributing WUs, then there is another problem, they are not getting to some of us at all. It's a all or nothing proposition.

There is no scientific value in having clients assigned to "nothingness". The science argument does not work. Its just a waste.

If there is a shortage of WUs, be transparent and say so. It's a good problem to have.

[cardnyl]

Just to update again. Of the remaining 4 uniprocessor clients which were unable to connect I stopped the processes, reconfig'd them to not use advanced methods, small packet size and 800mb memory available and they were all able to pull work (for now). Instead of the IP in question they pulled from the following:

171.64.65.65
130.49.240.81

I will probably leave them this way and cross my fingers that this workaround continues to work.

[umc]

server status said there's 0 WU available on .139