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

OCN putting the hammer down

Tom-Foolery?

Bears? <- im going with this one

Magic?
 
Tamales, Popcorn, and {root} Beer.
 
how does his 8 core setup have a 6903 ? ... or am i misunderstanding what he has or the new big adv stuff ?
 
Thread spoofing - just like you would do it for any other 8 core machine.

Mr. DAB rep, this would be a great time for the 16 core limit and decreased preferred deadlines.
 
If you look at that guys 6903 times (looking to 25 and 26), you see anywhere from 62min TPF to over 90+ min. Big ppd difference.
 
musky said:
Thread spoofing - just like you would do it for any other 8 core machine.
Click to expand...

Never thread of this. Is it a VMware and/or VirtualBox thing to tell the VM if there is more threads than actually present?
 
its a linux thing, there is a work around to make linux see more threads than you really have.
 
They just got their hands on a few 4Ps systems, and a few new 2Ps as well. Given most of this ramp is from HPCS, but then are still kicking it up a notch on their own.
 
I mean that link posted with 40-50+ clients running on HCPS? Is it just making multiple HCPS accounts or is there something else going on?
 
one of them knows someone who works at HP and is getting more than than 20 on his account. Others are using multiple accounts.
 
musky said:
Thread spoofing - just like you would do it for any other 8 core machine.

Mr. DAB rep, this would be a great time for the 16 core limit and decreased preferred deadlines.
Click to expand...

Look, it was all I was talking about a few months back in the DAB.....

It seems it was all much to do about nothing.

/shrug
 
hoth17 said:
one of them knows someone who works at HP and is getting more than than 20 on his account. Others are using multiple accounts.
Click to expand...

can't wait for the beta to end...

I guess TOS means nothing to those that threadhack....makes sense...
 
Thread spoofing to Cloud spoofing, Officially Corrupt Noobs are at it again. :rolleyes:
 
There are several members over at OCN that are running anywhere from 100 to 250 HPcloud cores taking a quick look at the stats of there top 10 folders I was able to pick out 6 I think that have a pretty big jump in points and then looking at Stanford stats they were running anywhere from 30 to 50 clients. Most of them had been in the 5000 to 20000 PPD range and in the last few days have jumped to the 100000 to 600000 PPD range. Just a rough guess I would say they are probably running around 1000 HPCloud cores as a team. And that could be a very conceptive estimate.
 
Some of us are still folding with our 4p even tho we have access to lots of HP beta things. But in the end I guess its supposed to be about the science, and I guess more of it is getting done.
 
Buckwheet said:
Some of us are still folding with our 4p even tho we have access to lots of HP beta things. But in the end I guess its supposed to be about the science, and I guess more of it is getting done.
Click to expand...

The method still matters, you don't see horrendous human cloning experiments being allowed 'because more science is getting done.'

Yes, I realize that I'm comparing breaking the good faith of a DC project and the intention of its maintainers with the ethics of human cloning. This is certainly hyperbole but I hope you see the point. This isn't a no holds barred race to get ever larger quantities of points, it is a quest to advance science through diligent and responsible contributions from the teams. Breaking rules and TOS, misrepresenting your hardware as something it isn't, and irresponsibly running big WU's on hardware that has a good chance of missing the deadline is in no way a net benefit to this project.
 
R-Type said:
The method still matters, you don't see horrendous human cloning experiments being allowed 'because more science is getting done.'

Yes, I realize that I'm comparing breaking the good faith of a DC project and the intention of its maintainers with the ethics of human cloning. This is certainly hyperbole but I hope you see the point. This isn't a no holds barred race to get ever larger quantities of points, it is a quest to advance science through diligent and responsible contributions from the teams. Breaking rules and TOS, misrepresenting your hardware as something it isn't, and irresponsibly running big WU's on hardware that has a good chance of missing the deadline is in no way a net benefit to this project.
Click to expand...

I don't disagree with your point about irresponsibly running big WUs on hardware that has a chance to miss deadlines. The rest is debatable because only PG are the ones who care about how the science is done. Which is why I made my statement of, some of us are still only just running our 4P systems even tho I could have spun up 300-500 cores on HPCS, but in the end more science is getting done. Lots of folks always say its not about the points, its about the science.

Nobody seemed to care that HPCS was running a soak test with their equipment. PG certainly did not speak out against it when they were putting up millions of PPD. Granted they were doing normal SMP work units. I don't really see any difference between them doing it or OCN, not to mention there are [H] members doing it as well, just maybe not to the scale a couple of OCN members are. When it was HPCS themselves running it more science got done, and now that there are OCN and [H] members doing it, while you certainly can question the sketchy bigadv setup, more science should be getting done and when setup properly is no different than what HPCS was doing.

I find it very hard to believe that if every one of the [H] members was offered the keys to HPCS and told you can fold on it, and you have our blessing, they would all say "No thanks it misrepresents our hardware." I think a lot of people would see a benefit to the science and to their team.

That does not however justify improper setups, recommendations to delete WUs, or anything that negatively impacts the science. This is why I have chosen not to be involved in the HPCS project with OCN.
 
the difference is that you guys are still running Big Adv on 8 threads, unless PG didnt implement the 16 thread limit?

when HP was burn in testing their stuff, they did -smp, not -bigadv.

And lets be brutally honest, as much as people say "its about the science" that utter bull shit, if OCN didnt care about the points, then they would be doing -SMP/-Uni, where there are backlogs, not -bigadv which has more than enough setup's to go around.....AFAIK no [H] member is running -bigadv on the HPCS beta, hell Musky last I knew was running 20 Uni CPU clients.

NOTE: People here at [H] are guilty of the same shit, just OCN does it on a much higher scale (ie: thread manipulation, that is just for fucking points dont try and spin it any other way, its the reason alot of us with 2600k's which met the requirement were not receiving -bigadv since quite a few otehrs were running x6's and 2500k's with Big Adv at the time)
 
I think I was making some edits when you posted. But I fully admit that there is a lot of irresponsible bigadv work going on with the OCN HPCS project.

I can't disagree with anything you said, other than, I haven't seen any information that could prove or disprove the number of people on OCN running the thread hack versus other teams.(HPCS excluded)
 
I'm not saying that OCN does the majority of the thread hacks, I am saying that as a team it is the only one I know of that openly pushes/endorses it,, which tends to lead to me believing that OCN is a driving force behind the thread spoofing. some of the 6903's your team mates are running will BARELY make the deadline, machines like Quad G34's, SR-2s and the like will finish it much faster because it was designed with these systems in mind, not a Cloud system with 8 threads.
 
travanx said:
Can someone explain the thread hack? What does that even mean?
Click to expand...

I'm not sure of the details, and [H] doesn't approve of the hack, so details aren't welcome here. In short, the thread hack tells Linux that you have more cores/threads available than you actually do. FAH then sees you have more threads and allows you to get the larger WUs (6903/6904).
 
Running bigadv is fine - 8 cores is still enough. Running 6903s and 6904s is not fine - this is where the thread spoofing comes in. I don't have a problem folding on HPCS - I am actually doing it myself with uni clients. What I do have a problem with is running the units designed for 12+ cores on this hardware.

Feather, I am sure [H] members are running bigadv on HPCS. Again, that is fine as long as you aren't mis-reporting core count. While I would like to see the 16 core requirement for bigadv implemented, it has not been yet. Therefore, bigadv on the big HPCS instances is fine.
 
W.Feather said:
I'm not saying that OCN does the majority of the thread hacks, I am saying that as a team it is the only one I know of that openly pushes/endorses it,, which tends to lead to me believing that OCN is a driving force behind the thread spoofing. some of the 6903's your team mates are running will BARELY make the deadline, machines like Quad G34's, SR-2s and the like will finish it much faster because it was designed with these systems in mind, not a Cloud system with 8 threads.
Click to expand...

When I joined OCN there was no pushing for the core hack for my 2600ks. I had 4 of them running normal SMP. I do know people did it, but it wasn't actively pushed per se. With HPCS it is different. It is in the tutorial. And if you actually go read the tail end of the thread there are people posting objections to the core hack being included because of the 6903/04 deadlines not being met. Grandpa was voicing his concerns in that thread as well. So there is disagreement among OCN members if this should be done or not. I chose not to partake.

If you can always return a 6903/6904 before the deadline I don't see a problem with doing it. The deadline is there for a reason, and at any time if PG feels it is not correct they can adjust it. I hope they do soon.

musky said:
Running bigadv is fine - 8 cores is still enough. Running 6903s and 6904s is not fine - this is where the thread spoofing comes in. I don't have a problem folding on HPCS - I am actually doing it myself with uni clients. What I do have a problem with is running the units designed for 12+ cores on this hardware.

Feather, I am sure [H] members are running bigadv on HPCS. Again, that is fine as long as you aren't mis-reporting core count. While I would like to see the 16 core requirement for bigadv implemented, it has not been yet. Therefore, bigadv on the big HPCS instances is fine.
Click to expand...

I agree with everything Musky has said. It seems like there is multiple things people are upset about.

1. Private access to HPCS that other people were not granted being granted to OCN members. This allowed them to bypass the core limit.

2. Members using multiple emails to circumvent the 20 core limit HPCS put in place for beta.(However some members told HPCS what they were doing and HPCS still granted them access)

3. People using the cloud poorly and recommending deleting WUs or improperly setting up the system when they know it might not make deadlines.

I don't disagree with 1 or 2(as long as you talked to HPCS). 3 however is a problem for me and as an OCN folding team member I do not agree with it at all.
 
The fact that a tutorial exists on OCN to circumvent the thread count limit is enough for me to think that the team itself supports the process.
 
W.Feather said:
The fact that a tutorial exists on OCN to circumvent the thread count limit is enough for me to think that the team itself supports the process.
Click to expand...

I have to agree.

Also, there has been much talk about shortening deadlines on the -bigadv in the DAB as many know.
I think it is needed and will proabaly happen.
 
Buckwheet, thank you for taking the time to write intelligent responses. It seems your views are not entirely aligned with the rest of your team.

To be clear, I am fine with people folding on HPCS. It is the thread spoofing (on both sandy bridge and the cloud) and general disregard for the impact of lost work units that makes me sick. I do not agree however that thread spoofing is defensible so long as they meet the deadline, this is a clear circumvention of PG's intentions and an afront to everyone else who responsibly respects the project.
 
PG has made it clear that time is of the essence for bigadv units, which is the reason for the minimum physical core count and somewhat tight deadlines. They would struggle to cut more from the deadline as it would begin to disqualify truely qualified systems, such as my dual 6128, which typically turns in 6903 and 6904s with about a day left before the preferred deadline. A 4.5ghz+ Sandy will outperform my 16p box, it also runs the risk of instability and loss of WU's due to the level of OC.

From a cloud perspective, performance can and will be so variable that I wouldn't trust it to finish a bigadv in time. Plus, Stanford is asking that bigadv be limited to 16 or more PHYSICAL processors, and in the virtual cloud, you get exactly zero....
 
W.Feather said:
The fact that a tutorial exists on OCN to circumvent the thread count limit is enough for me to think that the team itself supports the process.
Click to expand...

Kendrak said:
I have to agree.

Also, there has been much talk about shortening deadlines on the -bigadv in the DAB as many know.
I think it is needed and will proabaly happen.
Click to expand...

Just to be clear, these are in all the tutorials, and they are given with many many caveats in every other tutorial except the HCPS. I disagree with it "just being step X in the guide". People have asked for the same disclaimer to be added to the HPCS guide that exists in all the other guides talking about how to turn a 2500k/2600k, X6 machine into a bigadv machine. The disclaimer basically says it is irresponsible to use the core hack if your machine is not stable or a 24/7 machine. It says you will be negatively impacting the science.

Now all that being said, those guides were written well before HPCS and even before PG even made an announcement they were changing bigadv. After the PG announcement many of the discussions around the core hack evolved into "don't bother doing it get used to the SMP workload and points because its going to change soon." The guides were not updated to reflect this. The exception was HPCS.

R-Type said:
Buckwheet, thank you for taking the time to write intelligent responses. It seems your views are not entirely aligned with the rest of your team.

To be clear, I am fine with people folding on HPCS. It is the thread spoofing (on both sandy bridge and the cloud) and general disregard for the impact of lost work units that makes me sick. I do not agree however that thread spoofing is defensible so long as they meet the deadline, this is a clear circumvention of PG's intentions and an afront to everyone else who responsibly respects the project.
Click to expand...

So you and I are on the same page entirely, except when it comes to the core spoof. I will explain why.

I believe that the goal of PG is to just complete the science and generate cures. They felt they needed to add a carrot in the form of points to get the science done. So to me if you can build hardware that accomplishes the science within the deadlines set by PG then more power to you. If that system is a 4P G34 or a massively overclocked liquid nitrogen cooled 2600k I don't personally care. It is up to the end user to guarantee accurate results and not affect the science in a negative way.

Obviously, people interpret the rules by PG how they want, and nothing I say will convince people to change their minds. So what we are left with is how we choose to run our rigs for the research. We can make personal choices to not do what others are doing and live with the consequences, either positive or negative.

I guess I just don't see the core hack being any different then buying ES chips. Some teams forbid talking about ES chips and buying off fleabay and others don't endorse the core hack. Both claiming the other is against the spirit of the project. In the end every team I have looked at has its flaws. You just have to decide which flaws you can deal with and which ones you can't. I can live with OCN telling people how to do something, but it doesn't mean I am in agreement of doing it.
 
Schro said:
PG has made it clear that time is of the essence for bigadv units, which is the reason for the minimum physical core count and somewhat tight deadlines. They would struggle to cut more from the deadline as it would begin to disqualify truely qualified systems, such as my dual 6128, which typically turns in 6903 and 6904s with about a day left before the preferred deadline. A 4.5ghz+ Sandy will outperform my 16p box, it also runs the risk of instability and loss of WU's due to the level of OC.

From a cloud perspective, performance can and will be so variable that I wouldn't trust it to finish a bigadv in time. Plus, Stanford is asking that bigadv be limited to 16 or more PHYSICAL processors, and in the virtual cloud, you get exactly zero....
Click to expand...

There is where I think the argument turns weird. So you have a 16 core system that does X performance. I have a 5ghz totally stable Sandy. I get zero errors, you get zero errors. If time is of the essence and I can do more than your machine why is your machine "qualified"?

Its because of a core limit count instead of actual performance number count.

If a machine can't perform it shouldn't be qualified in my opinion. If that means my 4p 6128 doesn't qualify, so be it. If they (PG) truly wanted top performance then that is what they should go for. Just because I have an old 16 core 7 series intel server doesn't mean that it should be qualified for running bigadv.
 
Last edited:
can you please elaborate on how buying ES chips is the same as running the thread spoof? .... In terms of the project, not the teams.
 
Buckwheet said:
There is where I think the argument turns weird. So you have a 16 core system that does X performance. I have a 5ghz totally stable Sandy. I get zero errors, you get zero errors. If time is of the essence and I can do more than your machine why is your machine "qualified"?
Click to expand...

Because your processor is not rated to run at 5ghz as a stable, stock speed. If Intel was able to clock them to that speed reliably,then they would sell and warrant them accordingly. Due to the thermal and electrical stresses of running it above their "safe" speed, your processor is at a much higher risk for failure and/or instability over the course of time. Just because you're stable today, doesn't mean you will continue to be tomorrow when overclocked.
 
Is there a way to "undo" the corehack? Can someone produce some code to fix this? I didn't know this was a bad thing.. especially seeing it in all the guides. (since no one told me what this random code I was copy-pasting does)
 
That strawman argument against ES chips isn't even relevent. Regardless of where the chips came from, they meet the hardware requirements of the project. Core spoofed systems do not.

One violates the rules while one does not, they are not comparable.
 
If your running it now, just take off the "-bigadv" flag in your config file and your set....

colinstu said:
Is there a way to "undo" the corehack? Can someone produce some code to fix this? I didn't know this was a bad thing.. especially seeing it in all the guides. (since no one told me what this random code I was copy-pasting does)
Click to expand...
 
You must log in or register to reply here.
Back
Top