DAB & transparency

[orion]

(And if they decide that we should be part of the decision on what research should be done to "protect" the older hardware points, I am bailing out at that point.)

That is a non-issue in this discussion. No one here has said anything about us donors making research decisions and I doubt that the DAB has discussed PG handing over the reins of research decisions making to us donors. And I hope that PG never does that!

By the time that we do find what PG has decided our hardware purchases may have gone in the wrong direction. Some of us don't have that kind of money to throw around.

Yes, but PG doesn't know what decisions they will make either until they make them. That is research; it isn't a Ford production line.

And I don't know what I'm going to eat when going out until I see the menu. I might be in the mood for steak but decide on shrimp instead.

You can look at it like playing the stock market. We see the trends; we have history to look at. When we fill it is the right time to buy we do. We may do well we may lose our shirt but it was a decision that we made with the information we have at hand. That is unless someone has the ability to get what happens tomorrow today.

[mdk777]

But no matter how you make the decision or communicate it, someone will always be on the margin who just bought a new system that they wouldn't have otherwise. Changing the communication, even if that is needed, will only shift the decision point a little earlier or later, and change the people left out in the cold. So my advice has always been to not over-buy on a given technology. If someone wants to sink a lot of money into a given hardware level, then (as with the housing market), they could do either well or badly. You will hear from the ones who do badly.

good advice, but I reject your premise that a lack of perfect obviates the need for the better.
better = better
even if not perfect.

As I mentioned before, there is a world of difference between monthly, and quad-yearly updates on information.

[Macaholic]

Perhaps an open letter would help to organize apparent concerns and allow a proper response?

[Grandpa_01]

All of the answers I have seen here defending PG's lack of information / transparency are just plain excuses, PG has the information way before a beta WU is released when they first started on the writing of the current 8057 WU they new that it was x amount times faster they new it was going to provide x amount more PPD, they also new there were going to be some major implications from this such as 1 teams PPD went from 22,000,000 to 40,000,000 almost over night just from the release of 1 of these WU's, Moves like that creates a very unlevel playing field and can cause donor resentment towards PG. If you have enough of those types of move you soon will have no donors,

It would not have been hard at all for PG to let the folding public know what they were working on and how far along they were just the same as it would not be that hard to let us know today where they are as far as being able to port different classes of WU's over to GPU, Hinting to something 1 time 6 month 1 year 2 years ago then never updating progress and implications until release beta or public is just not a good practice and can cause donors some great expense. I do not believe this is a very good practice in donor retention and then to have the support forum say on top of that O-well that is the way it goes is not a smart move. That is probably the worst way to retain donors that I know of. PG really needs a PR person to help there image out with donors. I am pretty sure you would see allot more information / transparency from PG if there was someone there devoted to donor retention.

[Punchy]

Others have indicated that this was in the works for 5 years and that we should have expected it.
You say that the vagaries of research change overnight.

You both can't be right. But perhaps long established goals suddenly become feasible.

Actually, they both CAN be right. The potential of GPU processing was noted by Dr. Pande 5 years ago, but until an apples-to-apples comparison became available, the exact potential was unknown. Then, basically overnight, they found out, and us shortly afterwards with the beta.

However, communication improvements would address both. In fact, if you are correct, prompt communication becomes all the more critical.

"we understand that we had said this is the direction...but here are the reasons we are making a sudden departure from that course:...."


Finally, in case anyone was wondering, I have always supported the QRB, and have always supported giving the GPU points equal to the work done.

Heck...I pulled up a post from 7 years ago of mine proving my consistent position on the topic.

The point of this tread was not to hinder the progress of science, but to point out that better communication with donors would be an expedient.
I actually wholeheartedly support the current beta.

However, defending the way it is being communicated is the biggest joke I have ever read in life.
To those who see no flaws in this system, you are only deluding yourself.
The vast majority of folders who don't post here have already voted with their feet.

I guess I can't figure out exactly what you are asking for. You agree that the potential of GPUs has been noted for 5 years; you agree with equal points for equal work. Where is the "sudden departure"?

[mdk777]

Perhaps an open letter would help to organize apparent concerns and allow a proper response?

Not a bad idea, but I only represent myself.

Here is a modest proposal.

How about opening commit and change logs for public view like was instituted with V7?

this blog post

http://folding.typepad.com/news/2012/11 ... n-fah.html

lists important software initiatives that will affect FOLDERS.

The source code is really of limited use...a open commit and change log from PG, one that donors could follow would take a great deal of the guess work out of the equation regarding road-maps, timelines, mileposts, and the rate of progress.

"Let me see, how is the progress on Open MM for AMD going...hmmm.... there are 10 open critical driver flaws that are waiting resolution...and the last one took three months...I guess I shouldn't hold my breath..."

OR

"wow, they are on the last minor bug report on that GPU QRB project...I bet that it will launch soon."

While there is time required to maintain these TRAC systems, it is nothing compared to following and commenting on FORUM discussions.

How is that for a constructive and feasible suggestion?

[Jesse_V]

mdk777, here are two change logs:
FAHViewer: https://fah-web.stanford.edu/svn/pub/tr ... /ChangeLog
FAHControl: https://fah-web.stanford.edu/svn/pub/tr ... /ChangeLog
Note that it shows changes to 7.2.10 and 7.2.11, and the homepage only presents 7.2.9, so with those files you can see upcoming changes. There's also the Trac bug tracking website which is another layer of transparency: https://fah-web.stanford.edu/projects/FAHClient/roadmap

One solution to what you are asking for is to move all of F@h's open-source code from SVN to github.com. Github makes it simple to see commits, the code changes in those commits, and change logs. It also has a feature called a Pull Request, which makes it close to trivial for anyone to contribute a change or additional source code should they want to. Without using a private repository, I believe there's a disadvantage in that anyone could grab a developer build before Cauldron Development is done with it.

[mdk777]

I guess I can't figure out exactly what you are asking for. You agree that the potential of GPUs has been noted for 5 years; you agree with equal points for equal work. Where is the "sudden departure"?

I did not have a BA 8 rig, nor a BA12, nor a BA 16 rig.

However, I can easily understand those who buy hardware with the expectation of participation in the competitive points game.

People play games they have some expectation of "wining". When game rules change "unexpectedly" they get tired and quit.
To avoid this, you have agreed on methods of communication, oversight and accounting...so that everyone has equal access to knowing if, and how, and when, the rules of the game might change.

This is really not at all complex.

Saying something might change 5 years ago is entirely different from making that change today.

It seems so self-evident that I am really having a hard time believing anyone does not see it.

You can post a sign on a bridge "warning...metals have been know to show degradation in strength over time...creep rupture of support cables might occur at anytime over the next 50 years.."

However, this sign will not make anyone happy when the bridge collapses, nor will it absolve you of liability for maintenance as the bridge owner. Point of fact, posting the sing will make you more liable, because you knew of the condition, but did nothing to avoid the impending failure.

Periodic maintenance, analogous to periodic communication in our discussion, is what is required to avoid the shock.

[mdk777]

https://fah-web.stanford.edu/projects/F ... t/report/3

There's also the Trac bug tracking website which is another layer of transparency: https://fah-web.stanford.edu/projects/FAHClient/roadmap

Yes, that is what I am talking about.

I am not saying that donors should need to add, or have any access other than to be able to audit...watch the progress of development projects.

My guess is that such trac logs already exist on projects...it is a common way of having many people involved able to follow the progress and track responsibility.

As it is now, a blog post states that something is under consideration, and or development, and then 4 to 5 years later it is launched.

You can't expect people not to be taken by surprise by such developments.

Not communicating fails in two ways.

1. active highly involved/competitive donors are alienated.
2. causal interested parties have no reason to follow. ..information might come out next year...I might or might not remember to be interested enough to check again next year.

Result is the same...continuous loss of participation and donors.

[JimF]

It sounds reasonable to me to open up the logs for review, but I doubt that it will solve many problems. You will simply see the development process at an earlier stage, but with a corresponding greater level of uncertainty. For example, someone mentioned the new core_16 for AMD that never appeared. Viewing the early progress might have led people astray into buying the wrong card, only to have the development end for some unforeseen reason later in the process. It doesn't matter to me at all, since I will wait until they release something before making a decision, but I don't think it will solve the problem of needing a crystal ball.

[NookieBandit]

Like managing any complex project, communication and accountability is key to a project's success. I've made optimal hardware purchases purely by luck, and sub-optimal hardware purchases that could have been avoided had more information from PG been available before I made my purchase decision. I'm sure others have experienced that as well.

I've been a F@H contributor since 2009, and while my 55+ million points don't compare to many on this forum, I've had enough experience with F@H and reading this and several other forums related to F@H to summarize into 3 points what I think would go a long way to solving PG communications issues with donors.

1. Publish the software release roadmap for FAHClients, FAHCores and FAHViewers with a rolling quarterly one-year time horizon and what those releases will contain that pertain to hardware enablement, optimization and decremented/end-of-life for aging or non-supported platforms. Publish an additional one-year roadmap beyond the first that indicates ranked priority areas of development focus, which gives a donor a sense of PG's direction over a 24 month period.

The rationale is simple: With a public rolling quarterly development schedule, PG gives enough visibility to any donor considering a hardware purchase. Even if PG is late with code drops relative to the schedule, as long as the priorities remain in-place, a donor would be far more confident than they are today in their hardware purchase decisions. A good example: Many new donors are conflicted over the purchase of Fermi or Kepler cards. With the huge hit in performance core 2.25 gives Fermi and enablement but not optimization of Kepler, no one can say if or when the optimizations for Fermi will return and when the optimization of Kepler will be released. All that does is stall any purchase decision that can be stalled and limits new additions to F@H performance potential

2. For all FAH-dependent software, such as drivers, operating systems and development environments, PG should provide a quarterly update of all non-NDA information that consolidates the progress, or lack thereof, of these supporting software systems in the advancement of the FAH software roadmap.

It has been stated many times, both here an in other forums, that F@H is subject to the development progress in other areas in order for F@H to advance. With this information, donors would have additional information to make purchase decisions, but most importantly can apply pressure to those organizations falling behind in the development of tools and environments needed for F@H to advance. For example, having a few thousand AMD contributors pressure AMD to provide optimized support in their driver set for F@H could have a meaningful impact on AMD's development priorities. Donors can do more than just donate hardware and watts to the progress of F@H, and this is a good example. Another example is encouraging donors that are developers to contribute time to open-source development efforts where their talents can move the ball on F@H, but without knowing precisely where to spend their time, they can't help.

3. Before any work units are released to the general folding public, PG ensures that a wide-enough range of hardware systems have been used to benchmark them to ensure points consistency with the amount of work done, if the intention is to truly move toward “equal work = equal points”. Aside from internal testing, PG should use data obtained from those donors running the Advanced flag to tap a deeper pool of hardware results for verification.

The argument here is to be much more open with respect to how work units are assigned value. I could be wrong, but it appears to me that PG benchmarks against a very limited set of hardware before releasing the work unit to Advanced and then to the public. Once the data is obtained on the work unit, the results should be published in aggregate as a normalized value across the systems tested (as a mean and/or median). As hardware systems continue to improve, the performance factor would naturally rise which would benefit PG's research efforts by encouraging those donors with slower systems to upgrade to faster systems. Moreover, with published benchmarks over a range of systems, much of the bellyaching over mis-valued work units would be substantially reduced.

Beyond the above, PG should assign a product manager for the F@H program. Perhaps PG could recruit one of the Stanford MBA students looking for an internship or teaching-assistant position where the role would be consistent, timely and factually accurate communication with this forum on the above 3 points AND any information the Donor Advisory Board believes is relevant to the broader donor community. That person would also be responsible for broadening the reach of those that may be interested in becoming a F@H donor, getting corporate sponsorships to run F@H on their systems, and maybe even pulling together buying groups for F@H donors that may want to participate in a deep discounts on some Nvidia or AMD hardware if enough donors sign up. There is a lot more than can be done with F@H to stem the outflow of contributors with a very minimal amount of communication and meaningful donor engagement.

Since I'm not on any team ("default" suits me just fine), I'm guessing that Bruce is my DAB representative regarding these comments. If it is someone else, please let me know.

[Grandpa_01]

There is no need for a crystal ball if a person is kept abreast of progress plain and simple, these things do not develop over night and the information and the possible / probable implications are known far in advance of beta stage. The lack of information creates the need for the proverbial crystal ball.

[mdk777]

NookieBandit,

I was going to let your post stand as the conclusion of this thread...but since it is continuing...let me say.

BEST FIRST POST EVER

I agree 100%
Thanks for your considerable contribution to the discussion.

EDIT :
PS Macaholic, please consider this post my sign-on to this being an open letter to PG.

[Jesse_V]

NookieBandit,

I was going to let your post stand as the conclusion of this thread...but since it is continuing...let me say.

BEST FIRST POST EVER

I agree 100%
Thanks for your considerable contribution to the discussion.

Concur on all points, 100%. That was a concise and well-said NookieBandit!

I've been a F@H contributor since 2009, and while my 55+ million points don't compare to many on this forum, ...

55 million points is not trivial, no matter what rig you have. Sure, some people have more, but the majority of us, myself included, have far less than that.

Since I'm not on any team ("default" suits me just fine), I'm guessing that Bruce is my DAB representative regarding these comments. If it is someone else, please let me know.

Yes, Bruce is the DAB representative for this forum per http://folding.typepad.com/news/2011/11 ... d-dab.html

[Nathan_P]

Nicely said NookieBandit, especially for a 1st post and 55m points is still a hefty contribution to the project no matter what current rigs can do.

I'm olny going to add one thing to this, to prove that PG can sometimes get things nearly right. Last year they gave us 2 months notice of the changes to BA units, now many people, myself included, were not happy with the changes but at least we were given fair warning with plenty of time and testing to prove what machines did and didn't work. They also said that such units would be subject to yearly review - now that year is up and i haven't heard so PG - consider this a gentle reminder - not that the BA wu need any changes, 8101 is still tough enough to exclude all but the most powerful rigs

Whilst not perfect this was an example of how things should be done and not the current "here's a beta WU, allegedly doing the same work as the smp version, with a pile of points that bear no resemblance to the SMP WU that it mirrors, now fold it"