Folding Forum

k1wi wrote: I'd suggest that the reason a new points system hasn't been implemented is because it suffers the critical flaw in that it will be a change, and leave some folders worse off as a result.

Undoubtedly true. We can't walk on water. The benefit of it, would be a long-lasting one.

Personally, I liked the idea of "more science in less time, equals more points". Then problem with new features, etc., cause no concern. Better features that increase the work done per day, get more points. It doesn't mean older PC's get fewer points, but it does reward those who are upgrading their systems as they do so.

@mdk that was an interesting read about Rotman's BS turn around. Thanks for that. Martin's idea's of integrating to solve problems, was very interesting.

gimpy wrote: Is this TOO simple? X points pre hour of X hardware???? If it takes the "bench machine" x hours to complete the WU...so what? These are hypothetical points to satisfy man's(my, if that makes you feel bettr) greed or estimation of accomplishment for his efforts...See greed. Yes I'm human and envy noones accomplishments but it seems this "donor" program is promoting one up-manship? Read: Free enterprise system (greed).A man will spend a fortune to be seen as the "better man". If F@H wants to progress....need find a way to settle mans vanity equally? or perish? My P.C runs 24/7,uses same power and the cost still same as when I bought it.

It's too complex, actually. There are a CRAZY number of hardware choices out there. The list of various GPU's alone is absolutely stunning. We need something much simpler and able to encompass not only today's hardware and power costs, but those in the coming years, as well.

The power costs are best left up to us the donor, to work out. FAH can't get into the details of our power bills, for sure.

The benchmark machine is just to give a guideline for setting the base points for any new project's work unit. We can't have the same amount of points given to every wu. That would be hugely unfair.

Picture it like this: We have a big load of bricks at the bottom of a hill, and they have to be hand-carried up to the top of the hill (no road there yet). If you are giving $1 for every brick we carry up, that sounds fair. If you are giving $10 per hour, no matter how many bricks are carried up, that sounds quite unfair.

Wouldn't you want to base the pay according to the number of bricks that were carried up by that person? In a nutshell, that's what "points for science" idea is all about. It works well until you set up huge gaps between the projects (bigadv, in this case). Maybe there was a good reason to affix that high number of points to it, but there is a serious downside to it, as we see here with SMP.

All the complexities that Tim mentioned, become no problem, using that simple "more points for more science, quicker", idea.

As folders, we need to stay calm, and understand that older PC's will not be able to make more points, than they do today. From FAH, we need a more even-handed points system that does not include these sharp "push them off the cliff", kind of adjustments. Donors definitely become emotionally attached to their PC's that they've worked hard to buy and sometimes, hand build, expressly for FAH. FAH may not have wanted that kind of emotional attachment or PC's built just for FAH, but that's human nature, and FAH has benefited from it, hugely. Pande Group needs to respect that, and I believe that they do, but these planned adjustments are VERY severe, and very difficult for those affected, to deal with.

There is a reason for the big difference which is cost, to stay at the front end of things it is costly and if there was no reward for doing it, it just would not happen, the downside come when the cost becomes more reasonable to build the rigs and the reward is very big for the cost then you have lots of people building rigs that will meet the deadline and running them. Thus the reason for core / deadline limits. I myself believe 1 way to curb this is more frequent adjustments with a road map that says we will review bigadv requirements on Jan 1,,2014, April 1, 2014 July 1, 2014 and October 1, 2014 at these times it is most likely there will be deadline adjustments. That way we all know that if you are investing in a machine that is at the very bottom end ( by bottom end I mean barley beating the deadline on the slowest bigadv WU) there is a real chance it is only going to be able to do bigadv for a 3 month period. And this should be a sticky and well publicized. Right now you can build a bigadv capable machine for less than smp or GPU rig (it does take slightly more electricity to run them) so yes it does become lopsided and there are allot of them out there and most should have known that they were not going to be doing bigadv forever with them. It does not make what is happening right now any easier but it will help in the future.

The problem is with the lack of reward for smp and without a adjustment of points for them the problem is not going away, perhaps some day GPU's will take over where smp is but that day does not seem to be anytime soon since September there has been around 20 smp WU's released to beta and 1 core 15 GPU no core 17 GPU so that in itself says smp is going to be around for a while. On my 7 - 4P rigs I get between 1.9 Mppd and 2.1Mppd running smp I get between 5.5 Mppd and 6.3 Mppd running bigadv you could doubble the smp ppd output and I would still make 20% more ppd running bigadv. Please give the smp a little bit of love.

Adak wrote:Oh please:

And yet, no one, in many years, has been able to conceive a workable suggestion to improve the points system that didn't bring with it more problems than solutions, or more cost than benefit.

Either you're joking, or you mean a workable suggestion that will immediately be shot down by someone who has no clue how to implement it. Because absolutely, positively, a better point system could be set up. You simply don't have anyone who wants to work on it, who knows how to set up a points system. I understand that. They're researchers, not statisticians or handicappers.

Okay, since you seem so dismissive of my simple example, what is your solution?

Bill1024 wrote:So Tim what is your solution?

While rereading my post, I may have stumbled across a short term solution to the backlog of SMP projects. I'll write it up after I've had a chance to sleep on it. Instead of changing the rules of the game, one needs to use the existing rules to execute the change.

It may or may not help delay the BA changes coming, but I think the idea may have some impact.

Grandpa_01 wrote:There is a reason for the big difference which is cost, to stay at the front end of things it is costly and if there was no reward for doing it, it just would not happen, the downside come when the cost becomes more reasonable to build the rigs and the reward is very big for the cost then you have lots of people building rigs that will meet the deadline and running them. Thus the reason for core / deadline limits. I myself believe 1 way to curb this is more frequent adjustments with a road map that says we will review bigadv requirements on Jan 1,,2014, April 1, 2014 July 1, 2014 and October 1, 2014 at these times it is most likely there will be deadline adjustments. That way we all know that if you are investing in a machine that is at the very bottom end ( by bottom end I mean barley beating the deadline on the slowest bigadv WU) there is a real chance it is only going to be able to do bigadv for a 3 month period. And this should be a sticky and well publicized. Right now you can build a bigadv capable machine for less than smp or GPU rig (it does take slightly more electricity to run them) so yes it does become lopsided and there are allot of them out there and most should have known that they were not going to be doing bigadv forever with them. It does not make what is happening right now any easier but it will help in the future.

I agree with you that everyone buying a system for bigadv, must know that the obsolescence "reaper" is following behind, so you shouldn't buy the least powerful systems capable of bigadv, and then expect it to continue to fold bigadv, for several years. We know that won't happen, and it should be well known, both here, and throughout the folding teams, etc.

But I really disagree with you on the rest of your above statement. Cost, should not be an issue. One example: I have a high end 4P, and my buddy has a low end 4P, but with the same cpu's. Since my 4P cost nearly $1,000 more than his, if you take cost into account, then I should get more points clearly.

No, that doesn't work. And cost is not a necessary factor in a FAH point system. Keep the point system both simple and elegant, and fair as it can be:

"More science, faster, equals more points"

Repeatedly raising the bigadv threshold is unavoidable, however, raising it on short notice, in just two months between raises, is not the way to go. One raise in February, OK, but that second raise in April, with no reason given for yet another increase in the number of cores required? THAT is a real problem, imo.

The problem is with the lack of reward for smp and without a adjustment of points for them the problem is not going away, perhaps some day GPU's will take over where smp is but that day does not seem to be anytime soon since September there has been around 20 smp WU's released to beta and 1 core 15 GPU no core 17 GPU so that in itself says smp is going to be around for a while. On my 7 - 4P rigs I get between 1.9 Mppd and 2.1Mppd running smp I get between 5.5 Mppd and 6.3 Mppd running bigadv you could doubble the smp ppd output and I would still make 20% more ppd running bigadv. Please give the smp a little bit of love.

I agree. We need to increase SMP points.

The example you give is not what I am talking about, so what you buddy got a good deal in that scenario, it happens, but if you are going to get a top end machine you will be paying top dollar for it in most cases. If there is no justification for spending the $$$ are you myself or most anyone else going to build it. We can say cost should not be involved in it all we want, but the reality is it is. It cost many $1000's of dollars to own and operate top end gear my annual electric bill is just over $7500.00 so that is just over $1000.00 per 4P just for the electricity. That does not even include maintenance or build cost if you avg that out for say a 2 year life span of bigadv capable it would be around $2600,00 per machine per year to build maintain and power them and for most there is only 1 use for them (Folding), how many are willing to put that out if there is no justification for it. Cost is and will continue to be a factor when building top end rigs for bigadv if the reward is not there to justify the cost then there will be none to run them.

174,000 smp units need to be done and are in the server waiting to be sent out.
There are 182 BA wu ready to be sent out. Seems like a bit of a backlog to me.

I am sure most folders would turn their SMP killing 4P machines on those SMP wu if it were not for the loss of half their points.
Plus the fact people have to know that things are backing up. Not everyone hast the time to check server status, or would even think to.
Is this not obvious, common sense?
How many folders do not even know about this forum, I am sure quite a few.
They find out about folding through other web sites, and forums. Maybe when they got their PS3 years ago.

On a 4P if 2 people have the exact same CPUs and one person spent 1000$ more on parts. That person will only get the same PPD, as it should be.
Where in the heck did that 1000 dollars go, better PSU, memory. Why. That's like building a drag car and putting all the money in the paint job, not the engine.

"More science, faster returns, should equal more points"
Sliding K factor to the point SMP is 100% more PPD than it is now so even the most powerful 2P and 4P would not lose out doing them.

Adak wrote:
Snip

Repeatedly raising the bigadv threshold is unavoidable, however, raising it on short notice, in just two months between raises, is not the way to go. One raise in February, OK, but that second raise in April, with no reason given for yet another increase in the number of cores required? THAT is a real problem, imo.

On this we almost completely agree. PG probably thinks the two step change helps make up for the short notice. That a gradual change is not so harsh. BS.

Make ONE change and make it in April. Less hassle, less confusion, less work having to adjust deadlines and K factors, has the affect of giving a longer notice on when the next change will happen, less supposition about actual cut off dates, etc.

Rip the damn bandaid off fast not slow!

Bill1024 wrote: Where in the heck did that 1000 dollars go, better PSU, memory.

Let say: difference in sourcing ... Some buy retail, some buy ... ElSewhere

7im wrote: Okay, since you seem so dismissive of my simple example, what is your solution?

I know you're joking, but just in case you're not joking -- I'll be glad to! Give me the data on your work projects, and your priorities for the projects on a scale, so appropriate values can be assigned.

I know how to handicap, and a points system is just no problem for me.

You asked the wrong guy if you wanted a no answer, Tim.

Bill wrote: Is this not obvious, common sense?

Yes, there is a backlog, and yes, there are too many high end rigs focused on bigadv.This is not a bad thing - it's a sign that the points given to bigadv in the first place, were correct - big enough to motivate a lot of folders to invest in bigadv capable PC's. And the reason is POINTS. Lower points for bigadv a little bit (say 5% or so, nothing huge), and increase the points to SMP, by a bit more, and that backlog will disappear. Everybody notices an increase in a project's point values, and every team will be passing that news along. No problem getting the word out, and no moderator asking nicely in the forum, required.

@Grandpa, the problem I see with your suggestion of multiple increases in the bigadv threshold, over a short amount of time, is that it will alienate all the folders who have their bigadv PC's, pushed off and down into a much lower production in SMP projects. It may be an emotional reaction, but it's real, and we need to avoid that kind of antagonizing of the donors. Threshold increases should happen no more than once every year, at the most - never more. And, we need to increase the points for SMP so those donors who are "pushed off the cliff" by the higher threshold, will not have so very far to fall, in their ppd, as they settle back into SMP folding with their rig.

The points for bigadv would still be very attractive. There's nothing better in any DC project, anywhere. Of course it would be VERY attractive. It's a LOT of science.

I know all about the cost of electricity while running a 4P rig, 24/7. That's why I run just one of them, and not half a dozen of them. The build cost is quite manageable, but the expense of running them quickly becomes unreasonable for me. Not only would I have to pay for the electricity to run them, but I'm near the desert, so my air conditioning needs would skyrocket, as my home avoided being turned into an oven, as well. No thanks!

Having read through all the posts in this thread, it is clear that the problem remains with the high points allocated for the bigadv WU's (and of course the communication issues, but these have been covered).
It has been said many times "equal pay for equal work" - but it has also been shown many times that the same 4P machine crunching SMP's or bigadv produces massively differing points - where's the equality? It's not there because the bigadv points were heavily inflated. Yes, I agree with 7im and Adak that obsolescence will come to bigadv machines - it comes to all hardware (we've seen it on old generation GPU's). The solution is not inflation of other WU types to compensate for the existing flaw in the scheme, but would it not be more sensible to gradually ease off the bigadv points over time to bring it back into check?

So why can bigadv be changed and their systems relegated to less than have their former work, but an intel c2d is still getting the same work now as it did 3 years ago?

I understand making things bigger and better, but these units were meant to be run on corporate and server farms. I'm not an expert, but these huge systems are not upgraded as readily as a home user, so how is it right, for the lack of a better term, that the project use better faster hardware out there, that as reason that they start to exclude stuff. If it wasn't for the extreme f@h'er there wouldn't have been a fraction of the extreme core counts.

Why not have a modifier that is applied to whatever project or wu type that is the most needed? So when smp is needed this factor is changed till the need is gone. Then if gpu wu types are needed it is then increased for the criticalperiod.

DocJonz wrote:It has been said many times "equal pay for equal work" - but it has also been shown many times that the same 4P machine crunching SMP's or bigadv produces massively differing points - where's the equality? It's not there because the bigadv points were heavily inflated. Yes, I agree with 7im and Adak that obsolescence will come to bigadv machines - it comes to all hardware (we've seen it on old generation GPU's). The solution is not inflation of other WU types to compensate for the existing flaw in the scheme, but would it not be more sensible to gradually ease off the bigadv points over time to bring it back into check?

Doc, hopefully you don't mind me highlighting a couple of sentences I consider to be the essential parts of your post. As it happens, I agree with said essentials.

Since management/business analogies have been introduced to the discussion, I'll take a whack at it. Bear with me, I'm no management/business suit, just a poor copycat.

Anyway, times are harsh and some sort of compromise is called for. So, instead of letting a bunch of BA people go by raising the BA bar, would you as a whole accept a salary cut, say, -25% in PPD? BigAdv wouldn't be quite as "big" as it used to be, but in the light of current events, some action has to be taken. As per a message from our CEO (my highlight from http://folding.stanford.edu/home/change ... -full-fah/ ):

VijayPande wrote:With FAH GPU Core17 taking over the lion share of our calculations...

Seriously, wouldn't it be better to trim the fat from BA a bit, instead of fattening up everything else with it? And doing it less harshly than raising the bar to 24/32 cores on such a short notice? If you could rally behind something like "-25% salary cut", I do think it's something our DAB rep could actually present to PG as an alternative. If other DAB reps supported him, it'd carry even more weight.

Compromises are the sort of thing which makes everybody unhappy. However, all-out conflicts tend to have much more unpleasant consequences than some slight discomfort. On all sides.

Napoleon wrote:Anyway, times are harsh and some sort of compromise is called for. So, instead of letting a bunch of BA people go by raising the BA bar, would you as a whole accept a salary cut, say, -25% in PPD?

The problem with that idea is donors who run 2p/4p would be getting less compensation for the cost of running these systems which is not inexpensive.

If more SMP's need to be run then make it worth everybody’s time to run them. 2p/4p, i7's, c2d's etc...etc... Increase their points...that way everyone who runs them wins.

The hockey stick aspect of BA is what needs to change. It is ludicrous to me that returning work faster can have such an exponential effect. The way things are, one big rig (and for $7K I could pick up a 40-core Intel box) could be outproducing entire teams of dedicated folders.

It's not about increasing the others (although I do agree SMP has suffered over the last two years) but decreasing the BA QRB.