• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

171.67.89.151:8080

B

btomlins

n00b
Joined
Feb 10, 2004
Messages
33
Has anyone heard of this server not accepting work packets? I have like 5 machines all trying to connect to upload and it keeps failing. :mad:
 
You can always check f@h server status here.

It's not uncomon for servers to be temporarily unavailable.

Regards,
relic
 
:mad:
Even tried setting up a new machine, won't even get past requesting USERID from server.........

I can ping the servers, tracert to them works fine
 
Thats the one im having problems with. All my machines are assigned to this one server and cant get any work.
 
I finally got one machine back up and running, had to blow away the config file, thank god it sent my work and finally got some new work coming through folding away; this other machine though, the new one, I have no idea, I have tried the graphical client, blew away all registry keys, removed all folding files, started fresh, still nothing, starting to get pissed.
 
FINALLY!!!!

Got it all back working; apparently the config file was not pulling the right information from internet explorer to get out to internet, manually set that up and we are back in business; still does not explain why the graphical client did not connect cause I placed all that info in there correctly.

FOLD ON!
 
My [color=sky blue]experience[/color] is that the problem is not local, but at the assignment-server/WU-server end. Whenever this problem has happened to me a check of the Stanford servers show that the problem server (mostly 171.67.89.151) is, by their own admission, overloaded. I believe that the assignment server doesn't take "netload" into account as it ought to, sending user after user to the problem WU server, again and again. Perhaps this is a function of users using -advmethods because the assignment server sends users to .151 as that server contains the "beta proteins." That my "explanation" for why removing -advmethods might improve downloads. Yea, it's a crappy explanation but it's the best I have...

It wouldn't be so bad if the download failure would timeout quicker and assign the user to a [color=sky blue]different[/color] server. I've had boxen spend 3 or even 4 hours trying to get a WU from 171.67.89.151, then switch to another WU server and immediately download the WU. One problem is that it "tries" once per hour! :eek:

Vijay is aware of this problem. Their temporary solution has been to take 171.67.89.151 off the assignment queue for a short period. But the problem persists it seems.

How about...
Stanford needs a better algorithm for assigning users to WU servers -- an algorithm that takes into account "netload."
The client or assignment server needs to "recycle" faster, and automatically request a [color=sky blue] different [/color]WU server.
Stanford needs more WU servers.
Stanford needs to give bonus points for waiting. ;)

100000.gif
10000.gif
 
You must log in or register to reply here.
Back
Top