Accepting is the positive status indicator, meaning that the server is good to issue/receive WUs (unless I'm quite mistaken, but that is derived from old knowledge and looking at the possible sorting options at the top).
I only see 2 SMP servers down at this point, which is where bigadv comes from/goes to, along with normal SMP clients.
EDIT: Confirmed that "Accepting" is a positive status indicator under the "Connect" column, and the "Status" column has "full" meaning fully operational, as opposed to "accepting", which means only letting WUs return. Why they would use the same thing in two different columns to mean different things is beyond me.
0
Straight_ManGeeky, in my own wayNaples, FLIcrontian
edited September 2011
Then things have improved. Thanks for the update.
Standby can mean a server has accepted so many work unit result sets that it needs emptying and has safetied itself or been safetied by an assignment server. It will remain in standby while being emptied. It also can mean that the server was feeding work units only and needs filling with more work units. It will accept network connects from within FAH's core network but not from outside it.
The positive indication form of accepting means it passes a network function test, and down means it is even unable to respond to network queries from within the labs of FAH's core network.
I believe the two that were down earlier are now in reject status, though I did not note them (only their relative position in the "Client:SMP" filtered table. You may have had an assignment from that server, and your client tried to query the assignment server before it got cleared (so that clients would be referred to a different server for work, since the vast majority were up and running normally)
I just left it running and sometime overnight it accepted a wu so all is good on that end. Hopefully my last wu was sent in as well. I should probably remove -bigadv from this machine since I have discovered that it is only a single 2.0ghz xeon with hyperthreaded quad-core. At least I'm good with 12gb but I think I fall way short on the processor end.
If you don't have a WU, stop the client, clear work folder, and all files except the actual .exe and config file (so delete/move to another folder: work folder, queue.dat, fah.log, etc). Restart the client from cmd prompt with -configonly and confirm all settings (honestly, you can probably leave bigadv in, but you would want to monitor the total time it takes to finish a frame and compare that to preferred time.
Start the client after that and see if it pulls another WU or not. If not, post a log (just attach the file)
I noticed it again this morning when I got here but it corrected itself sometime during the morning. All you can do is leave it running and searching for work. Idle time sucks.
Comments
http://fah-web.stanford.edu/pybeta/serverstat.html
I only see 2 SMP servers down at this point, which is where bigadv comes from/goes to, along with normal SMP clients.
EDIT: Confirmed that "Accepting" is a positive status indicator under the "Connect" column, and the "Status" column has "full" meaning fully operational, as opposed to "accepting", which means only letting WUs return. Why they would use the same thing in two different columns to mean different things is beyond me.
Standby can mean a server has accepted so many work unit result sets that it needs emptying and has safetied itself or been safetied by an assignment server. It will remain in standby while being emptied. It also can mean that the server was feeding work units only and needs filling with more work units. It will accept network connects from within FAH's core network but not from outside it.
The positive indication form of accepting means it passes a network function test, and down means it is even unable to respond to network queries from within the labs of FAH's core network.
Start the client after that and see if it pulls another WU or not. If not, post a log (just attach the file)