Page 1 of 1
171.67.108.52 not assigning WUs [Resolved]
Posted: Mon Aug 18, 2014 8:58 pm
by billford
Code: Select all
20:37:51:WU02:FS00:Connecting to assign-GPU.stanford.edu:80
20:37:53:WU02:FS00:News: Welcome to Folding@Home
20:37:53:WU02:FS00:Assigned to work server 171.67.108.52
20:37:53:WU02:FS00:Requesting new work unit for slot 00: RUNNING gpu:0:GK110 [GeForce GTX 780 Ti] from 171.67.108.52
20:37:53:WU02:FS00:Connecting to 171.67.108.52:8080
20:37:53:ERROR:WU02:FS00:Exception: Server did not assign work unit
It's for a GTX 780 Ti, and according to serverstats 171.67.108.52 isn't a gpu server. I've waited abot 20 minutes and it doesn't seem inclined to direct me to a new WS.
Config etc:
Code: Select all
*********************** Log Started 2014-08-14T20:57:29Z ***********************
20:57:29:************************* Folding@home Client *************************
20:57:29: Website: http://folding.stanford.edu/
20:57:29: Copyright: (c) 2009-2013 Stanford University
20:57:29: Author: Joseph Coffland <joseph@cauldrondevelopment.com>
20:57:29: Args:
20:57:29: Config: C:/Users/bill/AppData/Roaming/FAHClient/config.xml
20:57:29:******************************** Build ********************************
20:57:29: Version: 7.3.6
20:57:29: Date: Feb 18 2013
20:57:29: Time: 15:25:17
20:57:29: SVN Rev: 3923
20:57:29: Branch: fah/trunk/client
20:57:29: Compiler: Intel(R) C++ MSVC 1500 mode 1200
20:57:29: Options: /TP /nologo /EHa /Qdiag-disable:4297,4103,1786,279 /Ox -arch:SSE
20:57:29: /QaxSSE2,SSE3,SSSE3,SSE4.1,SSE4.2 /Qopenmp /Qrestrict /MT /Qmkl
20:57:29: Platform: win32 XP
20:57:29: Bits: 32
20:57:29: Mode: Release
20:57:29:******************************* System ********************************
20:57:29: CPU: Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz
20:57:29: CPU ID: GenuineIntel Family 6 Model 60 Stepping 3
20:57:29: CPUs: 4
20:57:29: Memory: 3.47GiB
20:57:29: Free Memory: 2.57GiB
20:57:29: Threads: WINDOWS_THREADS
20:57:29: Has Battery: false
20:57:29: On Battery: false
20:57:29: UTC offset: 1
20:57:29: PID: 1104
20:57:29: CWD: C:/Users/bill/AppData/Roaming/FAHClient
20:57:29: OS: Windows Vista (TM) Business Service Pack 1
20:57:29: OS Arch: X86
20:57:29: GPUs: 1
20:57:29: GPU 0: NVIDIA:3 GK110 [GeForce GTX 780 Ti]
20:57:29: CUDA: 3.5
20:57:29: CUDA Driver: 6000
20:57:29:Win32 Service: false
20:57:29:***********************************************************************
20:57:34:<config>
20:57:34: <!-- Folding Slot Configuration -->
20:57:34: <power v='full'/>
20:57:34:
20:57:34: <!-- HTTP Server -->
20:57:34: <allow v='127.0.0.1 192.168.1.0/24'/>
20:57:34:
20:57:34: <!-- Network -->
20:57:34: <proxy v=':8080'/>
20:57:34:
20:57:34: <!-- Remote Command Server -->
20:57:34: <command-allow-no-pass v='127.0.0.1 192.168.1.0/24'/>
20:57:34:
20:57:34: <!-- User Information -->
20:57:34: <passkey v='********************************'/>
20:57:34: <user v='[Redacted]'/>
20:57:34:
20:57:34: <!-- Work Unit Control -->
20:57:34: <next-unit-percentage v='100'/>
20:57:34:
20:57:34: <!-- Folding Slots -->
20:57:34: <slot id='1' type='CPU'>
20:57:34: <client-type v='advanced'/>
20:57:34: <cpus v='3'/>
20:57:34: </slot>
20:57:34: <slot id='0' type='GPU'/>
20:57:34:</config>
Re: 171.67.108.52 not assigning WUs [Resolved]
Posted: Mon Aug 18, 2014 9:07 pm
by billford
Forgot I've had this before- deleted the slot and re-created it and now it's OK.
Re: 171.67.108.52 not assigning WUs [Resolved]
Posted: Mon Aug 18, 2014 9:11 pm
by Joe_H
I can't tell why the WS is not assigning you a WU or the AS not shifting you to another, but it definitely shows as a GPU WS for me when I check serverstats. It also shows WU's available.
171.67.108.52 VSP13 jadeshi GPU full Accepting 0.07 0 0 0 2448 2448 2448 146 0 0 0 1 WL_10000_F_8080G; WL_10000_F_8080G
Re: 171.67.108.52 not assigning WUs [Resolved]
Posted: Mon Aug 18, 2014 9:21 pm
by billford
Odd… the line I got was just:
52 171.67.108.52 vsp13a jadeshi classic accept Accepting 0.08 1 1
When I reloaded the page I got the same as you
One of life's little mysteries.
Re: 171.67.108.52 not assigning WUs [Resolved]
Posted: Mon Aug 18, 2014 9:53 pm
by billford
Thinking further about it…
I've noticed before that, occasionally, serverstats will show a server which I
know dishes out gpu WUs as classic, like the above. After its next script update (sometimes the one after that) it will correctly show as GPU.
So it seems possible that sometimes a gremlin creeps into the works. If my client happens to request a new WU while the gremlin is in residence, maybe the WS declines the request?
It would mean that if I'd waited a bit longer for the gremlin to move out the client would have picked up again of its own accord… and might explain why I've never come down in the morning and found it stuck waiting for a WU (I've got a lot more patience when I'm asleep
).
If it happens again I'll keep an eye on serverstats to see if the client resumes normal operation when the server shows as GPU again.
Re: 171.67.108.52 not assigning WUs [Resolved]
Posted: Mon Aug 18, 2014 10:14 pm
by bruce
I have reason to suspect that some kind of communications error between the server that manages the serverstat web page and a WS will cause default values to replace real ones. The "classic accept Accepting" must be default values for "GPU full Accepting" which appear to be the authentic state of the server. The "did not assign work unit" is probably another facet of the same error.
Tracking down and fixing such an error is certainly difficult since 1) it happens so rarely and 2) it won't get any attention when it seems to fix itself quickly enough that it's unobservable by PG.
Re: 171.67.108.52 not assigning WUs [Resolved]
Posted: Mon Aug 18, 2014 10:20 pm
by billford
bruce wrote:I have reason to suspect that some kind of communications error between the server that manages the serverstat web page and a WS will cause default values to replace real ones. The "classic accept Accepting" must be default values for "GPU full Accepting" which appear to be the authentic state of the server. The "did not assign work unit" is probably another facet of the same error.
That makes sense, thanks.
bruce wrote:
Tracking down and fixing such an error is certainly difficult since 1) it happens so rarely and 2) it won't get any attention when it seems to fix itself quickly enough that it's unobservable by PG.
You left out: 3) the best way to get rid of an intermittent problem is to be ready for it to happen again
edit- I've just realised that sounds as if I think PG ought to hang some monitoring on it… I don't, it was meant to suggest that it would be a waste of time!