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

Windows SMP Client Spitting EUEs

natermeister

Limp Gawd
Joined
Dec 26, 2005
Messages
463
Alright the last three work units I've had on my Windows SMP client, have ended early for some reason or other. Sometimes I get this message, sometimes I don't.

:42:27] Simulation instability has been encountered. The run has entered a
[14:42:27] state from which no further progress can be made.
[14:42:27] This may be the correct result of the simulation, however if you
[14:42:27] often see other project units terminating early like this
[14:42:27] too, you may wish to check the stability of your computer (issues
[14:42:27] such as high temperature, overclocking, etc.).
[14:42:27] Going to send back what have done.
[14:42:27] logfile size: 202047
[14:42:27] - Writing 202597 bytes of core data to disk...
[14:42:27] ... Done.
[14:42:27] No C.P. to delete.
[14:42:28] - Failed to delete work/wudata_09.sas
[14:42:28] - Failed to delete work/wudata_09.pdo
[14:42:28] Warning: check for stray files
[14:44:28]
[14:44:28] Folding@home Core Shutdown: EARLY_UNIT_END
[14:44:28]
[14:44:28] Folding@home Core Shutdown: EARLY_UNIT_END

Just too make sure no overclocking was causing the problems, I set my CPU and memory settings back to their stock values. There is nothing running overclocked in my machine and the temps are low, albeit a little higher than the last few weeks have been due to warmer weather.

Anyone have any ideas? I'd really like to get this problem solved if possible, it's going to kill my production.
 
Sometime, it's not your computer causing this but a bug with the WU itself. Normally, if you get 3 EUE in a row with the same WU, Stanford will send a different WU next time.

Normally, EUE units is still partially credited.

 
Well, I hope so. My computer is rock solid, so I know it's not what's causing the EUEs. In fact, I used to run it at 3.6GHz and it would hit 70C, but the WUs would still finish just fine.

I don't know what the problem is, but I'm down to just a GPU and a single K8 core and it's hurting me. Those nearly finished SMP WUs aren't getting credited.
 
The SMP Client/Work Units are a little more OC sensitive than the CPU Client/WUs. A stable CPU folding machine is not a guarantee of a SMP folding stability. Sorry. And it's an easy test to check. Back it off 200 MHz, and if the EUEs stop, then you know that's the problem. If not, back it off 400 MHz and try again. If it still EUEs at stock speed, then you know it's not the system.

The SMP client pushes a ton more data around, so a little more OC sensitivity is understandable.
 
The SMP Client/Work Units are a little more OC sensitive than the CPU Client/WUs. A stable CPU folding machine is not a guarantee of a SMP folding stability. Sorry. And it's an easy test to check. Back it off 200 MHz, and if the EUEs stop, then you know that's the problem. If not, back it off 400 MHz and try again. If it still EUEs at stock speed, then you know it's not the system.

The SMP client pushes a ton more data around, so a little more OC sensitivity is understandable.

Yes, I can testify of this. Even if my machine is stable at 3.4 for 24 hours with Orthos, it spitted out 0x0 or 0x1 errors till I lowered by 100 MHz and till now, it has been flawless.

 
Actually, it spit 1 EUE overclocked at two more at stock clocks. The work unit I'm folding now is at 94%, I'm crossing my fingers that it gets done.
 
Back
Top