171.67.108.13 not connecting to Work Server

[toTOW]

Did you try to change your client flags (adding or removing -advmethods) and settings (reported memory and small/normal/big WUs) to see if you can get a WU from another server ?

[Strawbee]

On 'normal' I get another server!

I thought it should always stay on 'big' so I didn't try to change that.

Off course these WU's don't give a lot of points but at least I'm folding again. Will try to set it back to 'big' after some completed runs to see if anything changed.

Thanks!

[Strawbee]

After 2 WU's on each console on another server it switched back to this one and yet again it can't get any work, even after 20 attempts... Changing to small doesn't help, it always wants to connect to this server.

Never mind: I just tried again by changing it back to 'big' (what started the problem it seemed) and now it uses another server that does work, really strange

[bruce]

The 20 retries is the problem. This can happen and when it does it can easily take as much as 20 minutes to recover, no matter how many retries are involved. There's no point in complaining until 20+ minutes have elapsed.

[Strawbee]

I meant 20 retries of the console to get work, meaning running for over a day without any succes, not restarting the console 20 times in a row. My previous posts also state that I've been having problems with this server for almost 3 weeks now, I think I had the right to complain And I still haven't found the solution to this problem, although at the moment everything is fine but after every WU it is possible that my consoles will reconnect to this one and I'll be out of work again. There doesn't seem to be any consistency with my settings, sometimes it works and sometimes it doesn't.

[legendno6]

I have 4 machines attempting to connect to 171.67.108.13, and all four started reporting "Unable to connect to work server" on Tuesday (February 9) morning. No work units on any of the 4 machines for over 24 hours. One was a laptop, and I moved it to a different network, and had the same result. I have restarted all four clients and rebooted all four computers, no change. Two of the machines are Linux, two are Windows. All machines have the same log entries:

[13:27:30] + Attempting to get work packet
[13:27:30] - Connecting to assignment server
[13:27:31] - Couldn't send HTTP request to server
[13:27:31] + Could not connect to Assignment Server
[13:27:32] - Successful: assigned to (171.67.108.13).
[13:27:32] + News From Folding@Home: Welcome to Folding@Home
[13:27:32] Loaded queue successfully.
[13:27:32] + Could not connect to Work Server
[13:27:32] - Attempt #5 to get work failed, and no other work to do.
Waiting before retry.
[13:29:02] + Attempting to get work packet
[13:29:02] - Connecting to assignment server
[13:29:03] - Couldn't send HTTP request to server
[13:29:03] + Could not connect to Assignment Server
[13:29:04] - Successful: assigned to (171.67.108.13).
[13:29:04] + News From Folding@Home: Welcome to Folding@Home
[13:29:04] Loaded queue successfully.
[13:29:05] + Could not connect to Work Server
[13:29:05] - Attempt #6 to get work failed, and no other work to do.
Waiting before retry.

[baz657]

Same here again and has been for a few days now.

[jball]

I am having the same issue with this server. The server status says its full and not in the accepting status. Could this be the issue? Why has the app not changed servers yet?

[bruce]

I am having the same issue with this server. The server status says its full and not in the accepting status. Could this be the issue? Why has the app not changed servers yet?

Are you able to open http://171.67.108.13:8080 and http://171.67.108.13 in your browser?

I don't see any "not" in the accepting status, and "full" is the correct status. (See the footnotes.)

Code: Select all

171.67.108.13	classic	vsp17v	gbowman	full	Accepting . . .

The fact that your suggestion about the serverstat information "full" and "not" indicate a problem may not be accurate, but I'm not suggesting that there isn't a problem. I see it in the numbers in the next two columns which indicate that the server is overloaded. CPU LOAD=6.25 indicates one type of overload and NET LOAD=151 indicates another type of overload. It's difficult to know what CPU LOAD is actually too high. The server could be doing a lot of background analysis work and as long as it's given a low enough priority it won't disturb the high priority tasks that upload/download WUs -- we just can't tell for sure. The NET LOAD, however, does indicate that a lot of people are trying to upload or download from that server at the moment, which may mean that something can be done about it or it may mean that the only option is for the client to wait until a good share of the backlog of internet connections has been processed.

[wintron]

having the same problem here . i have removed the classic client and then reinstalled it again . i have added the advmethods flags and then without the flag . changed work unit size from normal to big to small and changed the reported memory but to no avail . this has been going on now for the last two weeks .


i get an ok page in internt explorer when i ping the server. dont know what else to try . i have another pc on the netwrk which folds and it hasnt got any problems . surelt if it cant connect to an assignment server it should be able to connect to another one . correct ?

[bruce]

Getting an OK from the server is a good sign, but it doesn't tell you if the server has enough WUs to give you one when the client requests one. On Friday, there was a definite shortage of WUs for some (all?) classic clients. I suspect that the Pande Group worked during parts of the weekend to correct this problem but it's now Sunday night and we may have downloaded a lot of them. Hopefully more WU assignments will be added to the servers when additional staff are at work Monday or Tuesday.

[wintron]

ok thanks . i'll hold on for the next couple of days .

[wintron]

just a small update . after three weeks on nonfolding on this machine it has strangely connected to server 134.139.127.31 and has downloaded new core a0 and is folding again . dont know why it didnt connect to another assignment server in those three weeks beforehand . this all 24 hours ago

[whynot]

Because it did. Whatever happens after is out of your hands.

Code: Select all

assign.stanford.edu 	CNAME	vsp10v-vz00.stanford.edu
vsp10v-vz00.stanford.edu	A	171.67.108.200
assign2.stanford.edu	CNAME	vspg6-vz7.stanford.edu
vspg6-vz7.stanford.edu	A	171.64.65.121

be patient, blah-blah-blah

[j3pflynn]

Seems this server is having issues again. Delivered results but have been unable to get new work packet for 5 hours now.