171.67.108.13 - cannot connect

[jclayton228]

I have two machines (one Win2K and one Ubuntu) that are trying to get work units from the above address, but continue to fail. If I try to connect using my browser, I get an OK status, so it's not a firewall issue (8080 is blocked, but 80 is open). I'm pretty new at the whole F@H thing, so I'm not sure where to go next to try to figure this out. Any help would be appreciated. This has been going on for the last week or so.

Here is a snippet of my log file from my Ubuntu box.... My Win2K box log looks basically the same.

Code: Select all

[19:07:00] + Attempting to get work packet
[19:07:00] - Will indicate memory of 1010 MB
[19:07:00] - Connecting to assignment server
[19:07:00] Connecting to http://assign.stanford.edu:8080/
[19:10:09] - Couldn't send HTTP request to server
[19:10:09] + Could not connect to Assignment Server
[19:10:09] Connecting to http://assign2.stanford.edu:80/
[19:10:10] Posted data.
[19:10:10] Initial: 43AB; - Successful: assigned to (171.67.108.13).
[19:10:10] + News From Folding@Home: Welcome to Folding@Home
[19:10:10] Loaded queue successfully.
[19:10:10] Connecting to http://171.67.108.13:80/
[19:10:10] Posted data.
[19:10:10] Initial: 0000; + Could not connect to Work Server
[19:10:10] - Attempt #15  to get work failed, and no other work to do.
             Waiting before retry.

I am running v6.02 of the Linux version and v5.04beta of the Win2K app.

Thank you.

[new08]

This is not unusual for this range of server addresses Jay!
This is a very similar problem here
viewtopic.php?f=18&t=7605
-answered by VJ- and I currently have similar trouble on 108.20
I suggest it is just a matter of time to get results synched to server when re- coded.
With the amount that are on-stream and trying catch a backlog often -some wasted units are inevitable!
I report any problems,like you have,to flag it up in case it's been missed.
I've lost a fair number of units through this- but it is the way these multiple clients and servers interact from time to time.
Someone correct me if I'm wrong on this!

[jclayton228]

I've seen before instances where it took a little while to get a new WU. It just seemed strange to me that it has been happening for about a week now - it's never gone on this long.

Oh, well, I'll just be patient.

Any chance there's a way to force the application to choose a different server to connect to?

Thanks for the info, new08.

[new08]

Q: Any chance there's a way to force the application to choose a different server to connect to?
I think I have seen ref to this being done,possibly in config edit....but with current probs on server mods it may not remove the fog -so not recommended for experimenting.
It would be a way round all these server overload issues though!
On my current prob server 171.67.108.20 -CS shows as 0.0.0.0


Slot 06 *Active
Project: 4437 (Run 78, Clone 4, Gen 1), Core: 78
Work server: 171.67.108.20:8080
Collection server: 0.0.0.0
Download date: December 22 17:56:44
Deadline date: February 23 17:56:44

PF: 0.569380 based on last 4 slot(s)

[bruce]

There are several settings which modify the assignment process. This won't guarantee that you'll get a new WU, but they're worth a try.

Any of these settings can be changed to the opposite setting:
Add or remove -advmethods.
Change the BigWU setting
Some characteristics of your hardware influence the process, but you probably can change them.

If there's only one server for a particular category of projects and it runs out of work, you can't do anything except post here and hope that someone fixes an alternate sever or adds WUs to the one you're hitting.

[new08]

The main problem with my setups is uploading results, not getting new work.
This is what's frustrating as slower machines can take weeks to complete and it's not worth the power spent, apart from the frustration.
Fast multicores are the way to go...but most work is still done on older slower PC's by stats.

[bruce]

The main problem with my setups is uploading results, not getting new work.
This is what's frustrating as slower machines can take weeks to complete and it's not worth the power spent, apart from the frustration.
Fast multicores are the way to go...but most work is still done on older slower PC's by stats.

Work completed by the classic (uniprocessor) client has deadlines on the order of a month, so if a WU doesn't upload immediately, it will probably still find it's way home before it's a serious problem. That is certainly not true for the high performance clients (SMP, GPU, PS3) which demand better server access.

In either case, downloading new work is more important than uploading results. If your CPU/GPU goes back to work before the previous WU is uploaded, that's a good thing. That's why my previous post focused on ways to get a new assignment when you're stuck being assigned to a single server that isn't giving you work rather than a problem with uploading. Both are important, of course, but you really can't do anything about an upload problem while you might be able to change something that helps with a download problem.

The current load on the servers varies but is pretty close to the maximum that they can handle. (Some may be lightly loaded, but there are probably more that are over-saturated.) The rewrite of the server code has been mentioned in various places and it's currently being tested. We do know that the new code on the same hardware will have a much greater capacity, so I expect that the number of saturated server will go down significantly when this code is rolled out. (No, I don't know when that might be, but "soon" is the standard answer.)

The Pande Group is well aware of these problems and is working on a variety of ways to improve them.

[new08]

I realise the main points you make...but I have lost more than 10 units that will have gone round the loop again -as they hit deadlines.
Many folders get more frustrated than I do over it and they usually get a bit of placation. What else to do- it's the dynamic of the fold!
This new code is taking longer than planned to roll out- but getting it right is the priority, everyone will concur- even if cheesed off by lost work in the interim.
My only comment is that there needs to be a way to let people test portals and data stream function- to take at least one unlnown out of the equation.
This could be a small dedicated server with a test message using same protocols as WUs maybe?

[Leoslocks]

171.67.108.13
Haven't been able to get CPU work for hours. Is this server related?

[Leoslocks]

171.67.108.13
Heavily loaded when checked
The client is switching between 171.64.122.139 and 171.67.108.13 but unable to get work for 16 attempts

[toTOW]

108.13 seems to be low on work (only 70 WU to go at the time of this post) ...

[Grandpa_01]

Having the same problem as Leoslocks 2 machines trying to reach these 2 servers it has been happening for around 3 hrs now. All other servers connect and download WU's so it is not a connection problem. Is there any way to manually choose another server for the clients assigned to these servers.

[Leoslocks]

Client installed as a Service. Machine is remote so I have to get to the machine before I can restart the client.
Ctrl+Shift+Esc to launch Task Manager
Show Processes from all users
Services > Stop the particular service > Start the service
If it fails 4 times it goes into an extended delay
Stop Service > Start Service

Initial server was 171.64.122.139 and this server failed to download on the restarts also.

After sever successive restarts and the client switching to the alternate server, WU downloaded from 171.67.108.13

[Grandpa_01]

I now have 6 CPU system tray clients waiting on these servers. I will just switch them to SMP clients untill later.

[toTOW]

Same suggestion as for the other server currently having troubles : viewtopic.php?p=95087#p95087