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

P6701...Less then 7K PPD?

ccityinstaller

Supreme [H]ardness
Joined
Feb 23, 2007
Messages
4,237
I just got home and realized that my X6 rig is still crunching the same P6701, with a TPF of 8:10..This nets a whopping 6868.9 PPD...WTF is going on with these units?

 
Welcome to the suck lol

I would suggest removing the advmethods flag from your client, stick to standard A3s until Stanford addresses the issue, leave the 67xx units to guys with monster rigs
Posted via [H] Mobile Device
 
Welcome to the suck lol

I would suggest removing the advmethods flag from your client, stick to standard A3s until Stanford addresses the issue, leave the 67xx units to guys with monster rigs
Posted via [H] Mobile Device

The problem is that I have been crunching them at least 10K+PPD...I know I don't have hyperthreading, but 6 cores isn't exactly something to sneeze at..

 
You sure it's the same unit? Maybe you got a random flop, I've seen guys get those before
Posted via [H] Mobile Device
 
You sure it's the same unit? Maybe you got a random flop, I've seen guys get those before
Posted via [H] Mobile Device

It was the same unit...I finally completed it and am now crunching another 6701, only PPD is back up to nearly 11K...I had a feeling I should have just deleted the last one, but oh well..

 
It was the same unit...I finally completed it and am now crunching another 6701, only PPD is back up to nearly 11K...I had a feeling I should have just deleted the last one, but oh well..


That does happen at times as some work units can be wierd. The problem is that if it isn't crashing your system, the work unit still needs to be completed by someone and sometimes you just have to be the unlucky one who must bite the bullet. We stay for the points, but all of us started for the science. Luckily, anomalies like that don't happen often :)
 
Yeh the points are a bummer, but the WU is still going. Finnish it off some no one else will has to run though what you already have.

For the cure!
 
Like Kendrak posted, complete the WU. You can use the -oneunit flag so the client stops after the WU uploads, and then remove the -advmethods flag like Vaulter suggested if you have it running. Then check to see if you have advanced units enabled in your client config and reset it to accept only regular WUs..
 
Removing the -advmethods flag will not prevent you from getting P6701 and P6702 units.
 
From the fact that I am not using the -advmethods flag and I'm still getting them?
Hmm, very interesting, It's been close to two weeks and haven't seen hair or hide of one across 6 clients. I guess I could have overlooked a WU or two, I don't have my eye on every system all the time. Mind you, I did remove it from the client config as well and believe that you need to do this to make the setting effective. Therefore, a few possibilities remain to explain the difference between our two experiences...

A. you don't have it removed form the client config; B. I've just been lucky however the number of clients I am running and the duration of application suggest otherwise; C. Stanford is releasing them at a very low frequency and only a few people are getting them once in a while, or D. Stanford has moved them to general release and configs no longer apply, in which case we will all begin to see them with regular frequency. I do expect the latter point to be the case eventually if indeed these WUs were only directed towards advanced methods clients initially. I am not privy to info regarding when that would be or had been the case.
 
A. you don't have it removed form the client config
You really think I wouldn't have noticed that? :p

It's definitely gone. I removed it to see if it would make a difference and I grabbed a new 6702 right afterward.
 
You really think I wouldn't have noticed that? :p
No, I was pretty certain you would have, but it was one possibility among the list and I had to include it for the sake of completeness. I'm thorough that way. :p
 
hmm, i havnt gotten one either, but i'll check my logs again when i get home
 
[clienttype]
type=0

I assume this is right (no advmetods.) This machine has a 6701 right now, and 2 out of the last 5 units it has processed are 670X units. One theory I have is that if you have the -bigadv flag set, it overrides the fact that you do not have the advmethods flag set. I also have this:

bigpackets=big
extra_parms=-smp 8 -bigadv -forceasm

It has been running since Sunday and refuses to get a bigadv. My 4 other machines all have bigadv units.

On a side note, does anyone know what local means in the client.cfg file?
 
On a side note, does anyone know what local means in the client.cfg file?

It will run out of the directory the F@H exe is launched from. The queue, log, and work files will all be located inside that folder. You can set it to work in a different directory by setting the -d flag.
 
leave the 67xx units to guys with monster rigs

Actually, I think it's a scaling issue, so you're probably better off with a system closer to the benchmark i5 rig.

My SR-2 rig is putting out a whopping 55k right now. That's less than half of what it would do on an average A2 -bigadv WU. Yuck!
 
Kendrak,

Your are correct, as always, and that is why I let it run it's course. I have since finished one complete 6701, and now have another crunching at 11K PPD that is 88% finished..

I just assumed that was a bad WU, considering they pulled them not too long ago..

 
After removing advmethods, I've had two 6702s, one 6068, and now I'm back to a 6701. Losing the flag definitely does not prevent you from getting them.
I just assumed that was a bad WU, considering they pulled them not too long ago.
These units were not pulled.
 
Removing the -advmethods flag will not prevent you from getting P6701 and P6702 units.

Unfortunately this has become the case for me too. For over 3 weeks I did not receive any P670x units on boxes without the -advmethods flags.

I went though a re-check and all my clients do NOT have -advmethods on the CPU folding client, but unfortunately, as of this week, they've now started receiving these units.

While Stanford did increase the absolute/preferred deadlines on these units recently to accommodate dual-core SMP CPU folders, they continue to be a mystery as to WHY their performance is so much lower on Core I7s and other 6+ core boxes.

I understand they bench these with an I5 750, but it still doesn't explain the 25 to 40% PPD reduction over P60xx units. Even P604x larger A3 units show a lot more PPD.
 
While Stanford did increase the absolute/preferred deadlines on these units recently to accommodate dual-core SMP CPU folders, they continue to be a mystery as to WHY their performance is so much lower on Core I7s and other 6+ core boxes.

I understand they bench these with an I5 750, but it still doesn't explain the 25 to 40% PPD reduction over P60xx units. Even P604x larger A3 units show a lot more PPD.
Stanford cites their benchmark machines being responsible for the odd evaluation of WUs, but I never understood how such large discrepancies can occur. If we use our own machines, whether it's an i5, i7 or older Core2 architecture, a slower WU will take more time to complete. It's universal. The only difference between systems is the length of time. Longer running WUs need to have their values adjusted accordingly by increasing their base value and/or bonus to reflect this, not the contrary. I just don't get it and we're not alone.

It's my belief they actually need to be adjusted upwards, meaning higher PPD values to account for the longer time a system needs to stay running to complete the work. With relatively tight deadlines, we are committed to keep our systems operating for longer periods to complete bigger WUs at times we might desire to do other things, such as maintenance or just shutting down because of a heat wave, etc. This becomes a glaring issue for WUs that take half a week to complete speaking of the P2684. Moreover, if something comes up forcing a shutdown, we are penalized for losing a WU.
 
There's obviously something wrong with the benchmarking process, because if all units are supposed to produce the same PPD on a 750 then i7 machines shouldn't be taking PPD hits with any of these units.
 
There's obviously something wrong with the benchmarking process, because if all units are supposed to produce the same PPD on a 750 then 750 machines shouldn't be taking PPD hits with any of these units.

fixed to be even more blatant and obvious
 
Back
Top