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

GPU2 Server in Reject Mode.

Tigerbiten

[H]ard|DCer of the Month - February 2007/January 2
Joined
Sep 24, 2002
Messages
5,028
Heads up.

The GPU2 server, 171.64.65.20, is in reject mode at the moment.
So no new GPU2 work units.
Hopefully there is somebody at Stanford who can kick it ...........

Luck .......... :D
 
yea, kind of sad because i just got some overclocks ready to start testing on my GPU :p

 
I am seriously shocked that they would put only one server on the GPU2 client. With the mass amounts of new additional cards they new would be coming on board, I'm surprised they didn't assign 4 or more servers to handle it, especially with the really small WU's they have, because right now they have a HUGE amount of computing power just sitting here wasting time.
 
Yeah, I noticed this earlier and it's annoying as hell.

Also, it probably won't be fixed until Monday. Something to remember is that when something happens with the servers on a weekend, it's never fixed before Monday.

At least I finally got one of my quads back up and running by removing a hard drive from another system. It should take care of the loss of points from the GPU client.

 
Server 171.64.122.76 is up.
Just grabbed a GPU2 work-unit from it.
So now it just a question of how badly its going to get hammered if you'll get one.

Luck ............ :D
 
I am seriously shocked that they would put only one server on the GPU2 client. With the mass amounts of new additional cards they new would be coming on board, I'm surprised they didn't assign 4 or more servers to handle it, especially with the really small WU's they have, because right now they have a HUGE amount of computing power just sitting here wasting time.

Thats why if ya want something done properly don't trust a yank :eek:
 
looks like both servers are down now.
 
Server 171.64.122.76 is up but has no work.
Server 171.64.65.20 is down but has +50,000 work units.

Not good as its a holiday weekend.

Luck .......... :D

 
Is fixing a server something that can be done remotely? I can't say I know much about how servers work, but when I was in graduate school for chemistry we worked the weekends and evenings..... that's why chemists are [H]ard. :) They might get them working this weekend.

 
This is why it's good to have diversity in clients. I bet we widen the gap a bit more with OCAU :p

 
Pretty lame of the folding project team not to have more control of their servers. Anything can be done remotely if it's set up for it, and they should have some sort of alert to project server admins if this happens, or even some self-reset script or the likes.

Hope it comes back up soon. :)
 
Is fixing a server something that can be done remotely? I can't say I know much about how servers work, but when I was in graduate school for chemistry we worked the weekends and evenings..... that's why chemists are [H]ard. :) They might get them working this weekend.


Yes, servers can be rebooted remotely, so long as the server itself is responsive. If it crashed due to any hardware reason or the fail-over doesn't work, you'll have to actually physically reboot it.
 
I'm going on 9 hours now with no WU, but I also can't seem to send the last one in. The server status says its fine. (171.64.122.76) Not sure why I can't send since I can ping the server. Here's a snippet of the log.

[13:53:18] + Attempting to send results
[13:53:19] - Couldn't send HTTP request to server
[13:53:19] + Could not connect to Work Server (results)
[13:53:19] (171.64.65.20:8080)
[13:53:19] - Error: Could not transmit unit 05 (completed July 5) to work server.
[13:53:19] - Read packet limit of 540015616... Set to 524286976.

[13:53:19] + Attempting to send results
[13:53:20] - Couldn't send HTTP request to server
[13:53:20] (Got status 503)
[13:53:20] + Could not connect to Work Server (results)
[13:53:20] (171.64.122.76:8080)
[13:53:20] Could not transmit unit 05 to Collection server; keeping in queue.

Anyone know what status 503 means?

Thanks
 
hmmm . . . do the ATI GPU2 WUs come from a different server? I have been picking up ATI WUs just fine all night.:confused:
 
Woo Hoo..I'm back in business..just sent my completed WU and picked up a new one to chew on....:) :)
 
Looking at the server status page, I think 171.64.122.76 is the assignment server that feeds 171.64.65.20
So as 171.64.122.76 is up but 171.64.65.20 is still down, you can get to the assignment server but it connot send you to the work server.

The ATI work units are on a different server.

From the Support forums.........
Should be back up now. Some times there are issues which need human intervention, so these things need to wait until we wake up -- it's ~8:45am right now and yes we do need to sleep a little bit here and there The real question is why people didn't get routed to the backup server. We'll look into this. My first guess is that the shorter WU's are causing buildup in various aspects of Linux over time and we should move to longer WU's to increase its reliability.

It is back .......... :D:cool::D

Luck .......... :D
 
Yep, back up. My GPU's all picked up work as of 11:00 central.


 
I was SUPPOSED to cross the 500K threshold last night, but lost 8 hours of production from my GPU2 client. I finally picked one up about 15 minutes ago :(


 
We all lost some production preppy, we'll drink to your 500k today. a'ight? :D
 
Back
Top