• 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.

SMP server problems?

A

APOLLO

[H]ard|DCer of the Month - March 2009
Joined
Sep 17, 2000
Messages
9,089
I have all of my SMP machines not being able to send results to Stanford for at least 12 hours. Receiving work is no problem. Anyone else with this issue?

Edit: I just noticed that my GPU machine is also having the same issue. :confused:
 
I had one finish about 3 hrs ago that went through just fine. I've got another coming up in about 3 hours, so if it doesn't go through I'll update.

 
I'm just wondering if this could be a result from improperly updating the client? I've never had this sort of problem before. The client hangs at the "+Attempting to send results" message and then resumes working from the last frame. Strange.

If I can't resolve this before the end of the day, I will lose a significant amount of my work.
 
My SMP and GPU clients have both successfully sent in work within the last 12 hours, but I haven't updated either one yet soooo....

 
the one that sent in hadn't been updated, but the one that will be sending in has been updated, so i'll let you know then :D

 
It's actually closer to 15 hours, now that I think about it. The significant fact that no one else posted this problem and the preeminent environmental change is the updating of the clients leads to a probabilistic scenario favoring an error in the update procedure on my end. Someone please inform me of a possible error that can lead to this issue. All I did was replace the executable on all of my clients including the GPU client.

TIA
 
I have to agree with your theory. The 2 that I attempted to update went all kinda haywire...just hanging at "starting" if in service...or hang at "working" in console mode. After much monkeying with them, I got them to get work and start crunching, but I wont be able to look at them again until Monday.

I really hope you get this figured out. Lost work due to not sending, keeps me awake a night :(
 
Wharf_Rat said:
I have to agree with your theory. The 2 that I attempted to update went all kinda haywire...just hanging at "starting" if in service...or hang at "working" in console mode. After much monkeying with them, I got them to get work and start crunching, but I wont be able to look at them again until Monday.

I really hope you get this figured out. Lost work due to not sending, keeps me awake a night :(
Click to expand...
There are two clients that will almost certainly lose their work, more if this problem isn't resolved in the next couple of hours. BTW, what tweaking did you perform?
 
Do you really want that answered? LOL , I actually stayed at work 2 hours late messing with these things. Overall it was a frustrating process to be honest :(

I had 2 machines that were running the SMP client as a service... The steps I took were copy my work, -configonly to remove service, uninstall the old client, and reboot to remove the smpd that was still in use. Once back up, I would delete the old FAH directory, which I thought I was pretty much doing a "clean" install.

First machine I just got back from a user yesterday. I had removed the client before deploying it to them. Since I just go it back, I figured WTH, Ill throw the new SMP on it. When installing, all goes fine, until I get to the batch file. When I entered my credentials, it was telling me something along the lines of "Unable to save to the registry," and then asks me to enter my password again. Then I would see the 2 MPI lines with the message if you see this, MPI is working... After -configonly, changing my service account, and regeditting -forceasm, I reboot and the client starts. What I saw in the fahlog.txt was that it gets to "working," but just never advances. I removed and reinstalled many times, always coming back to the same issue. I now think this was an MPI issue.

Anyway on this machine, I just RIS'd a new image to it and started clean...which worked.

Machine 2 gave me a different set of problems, this one is my main workstation and was also running the client as a service. Same steps as above, but when I would reboot...my machine would sit at applying personal settings for a solid 5 minutes. When it would finally get to the desktop and I looked at services, FAH was stuck at starting, but would never actually start. I had to go into the Task Manager and kill fah.exe...and tried hacking everything out to give it another try...no luck. After hacking everything out the last time, I ended up running this thing as a normal console and just locking my workstation.

Both of these installs seemed to be working when I left...but I wont be able to check them until Monday...So i don't know if they have sent my units.
 
Sorry for long ass reply up there.

Did you copy the fah.exe right over the old one? Did you ever accept that license that they have in the new client?
 
Wharf_Rat said:
Sorry for long ass reply up there.

Did you copy the fah.exe right over the old one? Did you ever accept that license that they have in the new client?
Click to expand...
I simply copied the new exe over the old one as I did in the past, and the client started fine. How do I know if the licence was accepted? I didn't do anything else besides the exe overwrite. The clients are able to DL fine. The problem all stems from a single server 171.64.65.64.
 
Check your firewall is not blocking the outbound traffic.

Thats the first thing that sprang to mind.

Luck ........... :D
 
When I ran the -configonly for the new client, it made me answer y/n to a license agreement. Maybe it isn't accepting because you didnt accept this?

Try stopping clients and running -configonly to attempt to accept?
 
Wharf_Rat said:
When I ran the -configonly for the new client, it made me answer y/n to a license agreement. Maybe it isn't accepting because you didnt accept this?

Try stopping clients and running -configonly to attempt to accept?
Click to expand...

I did not have to do this and mine's running just fine... I'll see what the next wu has to say, i'm 98% into this wu.
 
Wharf_Rat said:
When I ran the -configonly for the new client, it made me answer y/n to a license agreement. Maybe it isn't accepting because you didnt accept this?

Try stopping clients and running -configonly to attempt to accept?
Click to expand...
Thanks for the suggestion. I tried it but the client just resumes working without asking for license agreement.
 
Can you see/ping the server.
Put 171.64.65.64 in the internet address bar and it should come up as ok.
If you try to ping 171.64.65.64 from a command prompt do you get a return or are the packets lost.

Both mine work .......... :cool:

Luck ............ :D
 
Yes, it comes up OK. The problem definitely lies with my clients. I'm surprised no one else reported this issue even though some updated the same way. I guess I'll need to do a complete reinstallation. Lovely...
 
Well it's nice to know I'm not the only one having problems with the SMP client. Hopefully it gets resolved with a further update, but until then I'm just going to run two instances of FAH. What a pain. This has really cost me already.
 
Certainly there must be a method to update all my clients without having to undergo a complete reinstallation? I already copied the fah.exe., is there something else that needs to be accomplished this time around that wasn't required with the earlier updates? Can I submit my license agreement without total uninstall and reinstallation?
 
on the one linux VM i upgraded, i just deleted everything but the client.cfg and then put the new files in the folder and it started right up....i made sure beforehand that all work had been submitted before i did so

 
OK, the results are being accepted gradually from some of my clients. My GPU client and two of my SMP clients uploaded. So, it appears it may have been a server problem. Will post further updates.
 
my updated SMP VM just sent through its first WU, so it seems like if there were problems associated with it, they're fixed for now...

 
Update: It appears that I just had all my stored WUs submitted. There were at least two servers affected from the looks of things. Initially, I thought it was only one. I'm really surprised no one else posted server-related problems... :confused:
 
I am starting to fear that my clients at work are having issues. My numbers seem low today, for where I think they should be. I have 8 q6600s that have the old client, I hope they didnt get restarted.
 
Wharf_Rat said:
I am starting to fear that my clients at work are having issues. My numbers seem low today, for where I think they should be. I have 8 q6600s that have the old client, I hope they didnt get restarted.
Click to expand...
If your clients were attempting to contact either server 171.64.65.64 or 171.64.122.76, then that would most certainly be the problem. The WUs are stored and they will eventually get uploaded so no need to worry unless they were completed close to the deadline. Best thing I can advise you do for now is wait it out like I did. You will definitely know by tomorrow if it's a server issue. My last couple of stubborn WUs seem to have all been submitted in the last half hour or so.
 
I'm still occasionally getting problems submitting my WUs to servers 171.64.65.64 or 171.64.122.76. I checked the server status here. Server 171.64.65.64 status is currently in 'reject' mode, but 171.64.122.76 is accepting. Why won't the WU upload? Furthermore, the client can't seem download a new WU to work on and I'm receiving the 'invalid address' notification...

Here's a relative portion of the FAHlog.txt file:

[20:42:06] Loaded queue successfully.
[20:42:06] - Preparing to get new work unit...

[20:42:06] + Attempting to get work packet
[20:42:06] + Attempting to send results
[20:42:06] - Connecting to assignment server
[20:42:06] - Successful: assigned to (0.0.0.0).
[20:42:06] + News From Folding@Home: Welcome to Folding@Home
[20:42:06] Work Unit has an invalid address.
[20:42:06] - Error: Attempt #1 to get work failed, and no other work to do.
Waiting before retry.
[20:42:07] - Couldn't send HTTP request to server
[20:42:07] + Could not connect to Work Server (results)
[20:42:07] (171.64.65.64:8080)
[20:42:07] - Error: Could not transmit unit 01 (completed February 11) to work server.

[20:42:07] + Attempting to send results
[20:42:11] + Attempting to get work packet
[20:42:11] - Connecting to assignment server
[20:42:13] - Successful: assigned to (0.0.0.0).
[20:42:13] + News From Folding@Home: Welcome to Folding@Home
[20:42:13] Work Unit has an invalid address.
[20:42:13] - Error: Attempt #2 to get work failed, and no other work to do.
Waiting before retry.
[20:42:33] + Attempting to get work packet
[20:42:33] - Connecting to assignment server
[20:42:33] - Couldn't send HTTP request to server
[20:42:33] + Could not connect to Work Server (results)
[20:42:33] (171.64.122.76:8080)
[20:42:33] Could not transmit unit 01 to Collection server; keeping in queue.
[20:42:33] - Successful: assigned to (0.0.0.0).
[20:42:33] + News From Folding@Home: Welcome to Folding@Home
[20:42:33] Work Unit has an invalid address.
[20:42:33] - Error: Attempt #3 to get work failed, and no other work to do.
Waiting before retry.
 
Stanford needs to hit the reset switch.

Or power cycle the 4-port linksys router or the cable modem in Vijay Panda's Pad.
 
My work machine running the regular client hasn't gotten a work unit for at least a day or two now. Unfortunately, Stanford's page is blocked by the webfilter so I can't see if it's a server problem that I'm having and I don't remember what server it was trying to connect to. It's only a P4 2.8 but hopefully it will grab a WU soon.

My SMP clients here at home are working just fine, though.

 
Does Stanford have a grace period for WUs that don't get submitted beyond the deadline?
 
You must log in or register to reply here.
Back
Top