Folding Forum

MtM wrote:@Leonardo Personally I kept quiet since you are one who's giving input to this thread in a concrete manner and one which I agree to be what was asked for ( I agree with your 3 points and your proposed fix ). Though I think you're not doing exactly what I had in mind it comes very close ( see the last post from mine where I talked about the flat line ), so there is no point in commenting on it as I already have done so. The 'fix' however I could not put in the form of a formula so if you didn't understand what I meant I will try to put it in flow diagram/pseudo code.

Somehow I get the feeling you're referring to me (Napoleon), not Leonardo.
Anyway, I've fixed the flat line issue in my initial proposal already. Time offset is now compensated with points_offset at Threshold both in pseudocode and the spreadsheet. Now there's convergence with the original, without the flat line at the proximity of Threshold.

VijayPande wrote:This one was a tough call. After much donor concern on this issue, we did our own research into the matter which showed that bigadv was out of balance. However, we know that any sort of points change will be unpopular. This puts us in a very tough position. If we do nothing, we're ignoring the majority of donors (i.e. "Pande Group doesn't care.") and going against our own data, in favor of the high end FAH donors (and some have called FAH "elitist" because of this). If we make the change that's right based on our own numbers (i.e. the change we've just made), we get the bigadv donors naturally upset, which obviously is very bad too. No way to win here.

In these tough situations, the best thing to do from my point of view as Director of FAH is for us to make the call that's best for the project as a whole, take the hits from those who will be unhappy, and move on and try to do the best we can from here. I can't guarantee everything we do is right, but I can guarantee that we take donor input seriously, take the time to investigate major issues to donors, and aren't afraid to make unpopular decisions to do what's right.

PS One question was why not give more notice. Here, our numbers were showing such high PPD (in some cases 500,000), that this was making a huge disparity for donors points. I did not want to give this another week to get worse. Also, in cases where there are points changes, we do not generally give notice. Please note that we will continue to give notice if a project type will be discontinued.

I'm sure point value's of various Wu's, Bonus's etc will continue to be a constant "juggling act", but it is supposed to be "all about the science" over everything else,
so as the one in charge of the project, if you tell me that the whole Bigadv project and it's bonus points, and then the current
reduction in those same bonus points for parity with other projects is, was always, and will continue to be 100% about the science 100% of the time,
then I'll happily fold as much as I can for as long as I can, it's obvious that going into detail of the decisions made "behind the scenes" would only lead to extended
arguements on both sides instead of working on more important tasks,
Rightly or wrongly points are the only way we have of putting any sort of "science value" on what we do, and receiving a little reassurance that is is still a valid way
of having some sort of reference as to the value of each project will make the changes made recently much easier to just accept and move on.

mdk777 wrote:

I guess it's more fun to reheat old issues using the same familiar arguments

No, insanely frustrating.

Hence my suggestion to move away from the specific issue, to the structural flaws, the process bottlenecks that hobble the project.

Trust me, I got your point already - I did use the word "frustrating" myself at some point, after all. Sometimes I just relapse to a style which just begs for a retort. You wouldn't be the first one to accuse me of having "wry way" of looking at things.
Anyway, we may be looking at potential solution(s) from different perspectives (EDIT: top-down vs ground-up), but I firmly believe that there's a point of convergence for both of them.

To misquote certain Frank S. - "I did it... wryyyy... wayyyy"

Napoleon wrote:

MtM wrote:@Leonardo Personally I kept quiet since you are one who's giving input to this thread in a concrete manner and one which I agree to be what was asked for ( I agree with your 3 points and your proposed fix ). Though I think you're not doing exactly what I had in mind it comes very close ( see the last post from mine where I talked about the flat line ), so there is no point in commenting on it as I already have done so. The 'fix' however I could not put in the form of a formula so if you didn't understand what I meant I will try to put it in flow diagram/pseudo code.

Somehow I get the feeling you're referring to me (Napoleon), not Leonardo.
Anyway, I've fixed the flat line issue in my initial proposal already. Time offset is now compensated with points_offset at Threshold both in pseudocode and the spreadsheet. Now there's convergence with the original, without the flat line at the proximity of Threshold.

Yes and sorry, I didn't check all the numbers from your second spreadsheet, another oops there.

@mdk777 thank you for elaborating.

I'm not really sure if I agree or disagree with you at this time, I think the forum should be the entity you describe, but maybe you're more hinting at the limitations of what the forum staff is allowed or capable of doing at this time.

I believe more excitement and enthusiasm could be generated and this particular problem avoided by one simple change.

Zero out all stats once per year. Start over from scratch.
Points issues go away and competition means something again.

You can't spend points. They will not prolong your life. They will not make you more attractive. You cannot put them on your resume.

Just one opinion among many...

Whenever there's a change to the points system lots of comments/feelings are generated. Only a few people (a) are able to look objectively at solutions which may benefit the project as a whole in spite of being contrary to their own interests. The rest of the people look primarily for solutions that benefit them personally. They fall into three categories: (b) Those who are benefited by the change, (c) those who would be hurt by the change, and (d) those who seldom pay any attention to the competitive nature of FAH.

Zeroing out the points would generate a large number of unhappy people who fall into category c. They may have been contributing to FAH for many years with uniprocessor clients / PS3 clients / GPU clients / even small SMP clients but they've never run a bigadv WU. As I read comments on this forum, the biggest single complaint is that the QRB awards those with access to corporate-class server hardware a HUGE advantage over those who don't have access to that class of computers. By zeroing out the points from years of small contributions you'd make that problem even more pronounced.

Folding@home originated as a way to make use of unused resources on small machines. Those who still fall into that category are still considered important to FAH even though the contributions of those who have bigadv-level hardware is very important to science. The problem is finding the proper balance between the two, and zeroing out history is not a step in the right direction IMHO.

Everyone keeps saying its all about the science, well drop the points system period, nothing, nill 0 and see what happens...

road-runner wrote:Everyone keeps saying its all about the science, well drop the points system period, nothing, nill 0 and see what happens...

All 7 of my rigs would still be going.

My previous post on this thread was very personal. I will now like to ask a question.

There was mention of "supply and demand". In this context, I do not understand what "demand" means. We donors are not buying anything and PG is in complete control of supply. This is not a market, in my view. Why should "demand" enter into anyone's calculus about points?

Indeed, zeroing out 10+ yrs of history would be very counterproductive and unhelpful.
It wouldn't help the current situation one iota !

It 's about the 'demand' for Work (Units) by systems running at donor locations. When demand outstrips supply, (too) many systems are running idle.
With current and future energy costs, that 's not a good deal for most donors. Not alone are there energy costs, but long term also hardware cost inefficiencies when systems run too much time idling in stead of Folding (a.k.a. science) ...
EDIT: it will also create artificial (unwanted) differences between donors and/or teams when only a certain type of WU is 'out of supply' regularly.

The Demand part is directly related to keeping the servers balanced.

If the active science projects require 10000 trajectories for bigadv and 80000 trajectories for smp and 50000 trajectories for GPU and 60000 trajectories for uniprocessors, servers are configured based on those numbers. Now if 50000 donors want to run bigadv, there will be 40000 clients who can't get their choice of assignments. Demand exceeds Supply in that category. Having them continually banging on the servers that have run out of bigadv projects does not contribute anything to science and it certainly contributes to the frustration level of a lot of donors.

(I invented all those numbers -- they probably are totally unrealistic, but that doesn't matter -- there's still a fixed number of trajectories on each server which are either checked out to a client who is processing it or waiting for someone to request that assignment. Those fixed numbers do change when new projects are started or when projects end. The number of donors seeking work in each classification changes, too, for a number of obvious reasons but there has to be a reasonable balance between the two.)

bruce wrote:The Demand part is directly related to keeping the servers balanced.

If the active science projects require 10000 trajectories for bigadv and 80000 trajectories for smp and 50000 trajectories for GPU and 60000 trajectories for uniprocessors, servers are configured based on those numbers. Now if 50000 donors want to run bigadv, there will be 40000 clients who can't get their choice of assignments. Demand exceeds Supply in that category. Having them continually banging on the servers that have run out of bigadv projects does not contribute anything to science and it certainly contributes to the frustration level of a lot of donors.

PG specifically states that there is no guaranty that bigadv projects will always be available. When no bigadv wus are available smp wus are supposed to be issued instead. All machines capable of running bigadv can run regular smp really, really fast. My bigadv machine returns regular smp wus at a faster rate than my 8800gs returns GPU wus.

If the server's can't deliver SMP wus fast enough to keep most donor's machines running most of the time, then PG has to decide if they have the resources to do more science on their end to take advantage of the computational resources available.

I disagree with the concept of "demand" in this arrangement. IMHO, donors are donors, not consumers of wus. Since computation has no shelf life, donations in excess of needs can't be stored. That is PG's problem to solve. If they choose to solve it by refactoring how points are awarded, that's fine with me. PG has to be careful, though. There are other DC projects that would love to have bigadv capable donations and donors can change projects easily and quickly.

The "supply and demand issue" raises more questions as to the prudence of such a devaluation that was imposed on the Bigadv Wu's,
I still feel the main contributor to the discontent among "the majority of donors" was the release of the new, bigger Wu's without any real
change in deadline times, when released the original Bigadv Wu's had an 8 core requirement, and due to the overclocking ability of the hardware,
and the expertise of the donors, quadcore i7's and the newer "SB's" could glean a nice bonus as their return times were within the stated deadlines,
but with the bigger Wu series and it's hardware requirement of 12 cores there are "tricks and scripts" floating around that still allows machines
with less than 12 cores (or hyperthreaded 6 cores) to run them, and although still within bonus deadlines it just means less Wu's for the small
percentage of donors who have the high end hardware these Wu's were targetted at, and no, that doesn't include me when I talk of those with
multi socket boards and 12 or more actual cores (or 24 or more hyperthreaded),
With the original Bigadv Wu's, even though a hyperthreaded quadcore wasn't targetted, the systems still presented the required 8 cores to the Fah client,
but having "a way to trick" the client into believing the machine has more cores than it has isn't, I believe, fair or "in the spirit" of Folding,
So instead of just a larger "across the board" reduction of the whole Bigadv project, a lot of issues could've been settled more fairly by a more modest reduction
in the bonus percentage along with a tightening of deadlines, and especially for the new Big, Bigadv Wu's, which would go a long way in the "supply and demand"
question, as well as allowing those with dedicated and expensive hardware to see a just reward for their efforts,
And as far as comments go about such high end hardware now being somehow "more affordable", that may be true of say a single socket hyperthreaded hex core system,
but server class boards and Cpu's are still way more expensive than "consumer level" hardware, and they always will be.
I'm still reading through all the posts in various threads, and some indeed show the depth of feeling behind the project, but at the moment I'm still undecided if I should
just "have faith" that all my efforts over the years are taken as seriously as described and just "soldier on regardless", look around for other worthwhile D.C. projects,
or just ditch the whole thing and make a worthwhile cash donation to some other needy cause,
If I didn't have such a long term affinty with Folding I'd have posted the last few lines in my starting post and not here, seven pages later.

While there are other DC projects out there you and I and most of the people that fold know that the vast majority of the other DC projects are not managed nearly as well as FAH is. Most of them run out of work on a regular basis there is very little involvement from the originators of the work units and for some reason allot of the WU's have high failure rates. You need to give cred here where credit is due the people at Stanford FAH do a far superior job at administrating FAH than the administration of the other DC projects do. And if people do not know of the downfalls of the other DC projects it just takes a couple of days of running them to figure it out. I have and still do on occasion run Boinc projects if I am asked to for team competition's and it can be very frustrating at times. Especially if you run FAH and get used to the job they do of managing the fah projects vs. the Boink projects.