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

Project 2605 causes client-core errors

D

D-OveRMinD

Weaksauce
Joined
Aug 22, 2005
Messages
111
I keep getting this damn WU over and over, and it keeps giving me the same error.

I am running two Ubuntu 7.10 VM's on Vista 64, both with the SMP client. One works just fine, the other keeps getting this problematic WU.

Here's the log:

[16:07:17] Project: 2605 (Run 4, Clone 37, Gen 7)
[16:07:17]
[16:07:18] 2605 (Run 4, Clone 37, Gen 7)
[16:07:18]
[16:07:18] Entering M.D.
[0]0:Return code = 0, signaled with Floating point exception
[0]1:Return code = 0, signaled with Floating point exception
[0]2:Return code = 0, signaled with Floating point exception
[0]3:Return code = 0, signaled with Floating point exception
[16:07:29] CoreStatus = 0 (0)
[16:07:29] Client-core communications error: ERROR 0x0
[16:07:29] Deleting current work unit & continuing...
Click to expand...
Now multiply that over and over...no matter if I delete the Work forlder and Queue files, it keeps pulling down that WU.

Apparently, the 2604 and 2605 have both been this way for some time. But I need to know if there is a way to get past this. I just bought a q660 rig and now I can't even use it!!!!


 
I'm running at less than one bad work unit every couple of weeks.
So it's only around 1 in 250 bad WU at the moment for me.

With the SMP client, you'll normally pull the same bad work unit 3 times in a row before you get a new one.
If you've very unlucky, you'll get it a multiple of 3 times ...... :mad:

Also is your system running at stock speeds or is it overclocked.
If overclocked, set at stock speed to chrck it not the overclocks fault.

Luck ............. :D
 
Tigerbiten said:
I'm running at less than one bad work unit every couple of weeks.
So it's only around 1 in 250 bad WU at the moment for me.

With the SMP client, you'll normally pull the same bad work unit 3 times in a row before you get a new one.
If you've very unlucky, you'll get it a multiple of 3 times ...... :mad:

Also is your system running at stock speeds or is it overclocked.
If overclocked, set at stock speed to chrck it not the overclocks fault.

Luck ............. :D
Click to expand...

I had to fiddle around with my E2160 for about a week to find it's happy spot. Errors left and right if I tried to push it.

 
Damnit...yeah I'm overclocking a q6600 to 3114mHz. What was the point of getting this then? I hate betas...
 
The client core communications error is usually a case of the client not being properly set up.

At the very least delete that Linux folder and client and reinstall the client. Worst case reinstalls Linux within VM.

As a rule VM and Vista 64 don’t work and play well together but you can make it work.

One client #2 be sure to name it #2 during the last stage of configuration. Also, try the good old –local with your –forceasm flag.

Luck


 
D-OveRMinD said:
Damnit...yeah I'm overclocking a q6600 to 3114mHz. What was the point of getting this then? I hate betas...
Click to expand...
It might not be the fact that the client is beta. It has been in beta for a long time now. You really should try this at stock frequency to see if it is a hardware issue.

 
APOLLO said:
It might not be the fact that the client is beta. It has been in beta for a long time now. You really should try this at stock frequency to see if it is a hardware issue.

Click to expand...

Yup, the client works fine for thousands of other folk and when that happens you have to look elsewhere;)

 
I've finished 881 p2605's ........... :eek:
At just over a day each that 2.5 years folding time.
In all that time I've only had 2 or 3 bad work units from this protien.
It this one. Same WU multiple times.

Put your clock bad to stock and see if you can run it ok.

Luck ............. :D
 
I've finished 112 of them myself...On WUs that I know are stable, if I see errors like that, it's either a result of not getting enough power to the CPU, or the result of an overclock that is too far to be considered totally stable. The OS can be stable at a lot of overclocks, but programs needing high precision floating point arithmetic will suffer from overclocks gone too far.
 
BillR said:
The client core communications error is usually a case of the client not being properly set up.

At the very least delete that Linux folder and client and reinstall the client. Worst case reinstalls Linux within VM.

As a rule VM and Vista 64 don’t work and play well together but you can make it work.

One client #2 be sure to name it #2 during the last stage of configuration. Also, try the good old –local with your –forceasm flag.

Luck


Click to expand...

I thought I was supposed to use the -smp flag instead of the -local flag.

Also, I thought you only needed to make the ID 2 if you had multiple folders on the same rig. Since the two VM's are mutually exclusive of one another, is that needed? I've never had to do that before.

I will try all the different suggestions and see what works.
 
D-OveRMinD said:
I thought I was supposed to use the -smp flag instead of the -local flag.

Also, I thought you only needed to make the ID 2 if you had multiple folders on the same rig. Since the two VM's are mutually exclusive of one another, is that needed? I've never had to do that before.

I will try all the different suggestions and see what works.
Click to expand...

VMs and Vista 64 work just fine together thank you very much. You just have to boot with the signed drivers disabled. :D

Anyhoo, you shouldn't need to switch the ID or run with -local. I've never had to on my quad, and that's 2x VM in Vista Business x64.

Definitely check stability with your overclock though. It may be worth a shot trying Prime95 or something similar, since those are also somewhat prone to floating point errors caused by overclocks pushed a touch too far.

 
Another vote for stress testing. I stress test the piss out of every overclock I do to make sure I won't have any folding problems. I don't want it sending back bad work and stuff like that. Besides, I hate random crashes and errors with my system which can be avoided.

 
0x0 errors is usually caused by a few things : permission issues (not being able to write files to disk or updating them) or memory errors. A Q6600 at 3.1 GHz is nothing but memory might be a different thing.
 
Xilikon said:
0x0 errors is usually caused by a few things : permission issues (not being able to write files to disk or updating them) or memory errors. A Q6600 at 3.1 GHz is nothing but memory might be a different thing.
Click to expand...


I have a sneaking suspicion you are right about the permissions. I will look into that.
 
D-OveRMinD said:
I have a sneaking suspicion you are right about the permissions. I will look into that.
Click to expand...

Since you are in Vista, I've heard reports of the OS not liking programs writing to the Program Files directory, though I can't confirm that since my VMs don't write to there. Might be worth a shot trying the client in something simple as C:\FAH or whatever, that you know has full permissions for read/write access.
 
I got a bad 2605 over night. Errored out at around 44%. I'm thinking I might have to back my B3 back down to 3 GHz.

 
5 weeks with numerous boxes, not 1 error yet, knocking on wood. Stress test to hell and then when you find stability back it down just a hair to give you a margin of safety for things like slightly clogged HSF, days where your ambient temps reach 80F plus.. etc.

 
Looking at the log, I definitely need to back it down. I thought with a P35 board the B3 could go a bit higher, but it's still a B3. I wish the program be more forthcoming about errors instead of just burying the error in the log and moving on.

 
aldamon said:
Looking at the log, I definitely need to back it down. I thought with a P35 board the B3 could go a bit higher, but it's still a B3. I wish the program be more forthcoming about errors instead of just burying the error in the log and moving on.

Click to expand...

I agree, too bad there is no a errors.log.

 
You must log in or register to reply here.
Back
Top