DAB & transparency
Moderators: Site Moderators, FAHC Science Team
-
- Posts: 10179
- Joined: Thu Nov 29, 2007 4:30 pm
- Hardware configuration: Intel i7-4770K @ 4.5 GHz, 16 GB DDR3-2133 Corsair Vengence (black/red), EVGA GTX 760 @ 1200 MHz, on an Asus Maximus VI Hero MB (black/red), in a blacked out Antec P280 Tower, with a Xigmatek Night Hawk (black) HSF, Seasonic 760w Platinum (black case, sleeves, wires), 4 SilenX 120mm Case fans with silicon fan gaskets and silicon mounts (all black), a 512GB Samsung SSD (black), and a 2TB Black Western Digital HD (silver/black).
- Location: Arizona
- Contact:
Re: DAB & transparicy
In some areas, FAH is an early adopter. It was the first DC project with a GPU client. And the first DC project with a true SMP client. First to have a PS3 client.
How to provide enough information to get helpful support
Tell me and I forget. Teach me and I remember. Involve me and I learn.
Tell me and I forget. Teach me and I remember. Involve me and I learn.
Re: DAB & transparency
Replace "areas" with "decades" and I'd agree. It seems that other DC projects are now adopting new technology much more rapidly. AVX is a good example.7im wrote:In some areas, FAH is an early adopter. It was the first DC project with a GPU client. And the first DC project with a true SMP client. First to have a PS3 client.
Back to the thread topic...
-
- Posts: 45
- Joined: Sat Oct 27, 2012 6:17 pm
- Hardware configuration: AMD Opteron 2 x 6274 (32 Cores)
AMD FX-8350 (8 Cores)
Intel i7-4790K (8 Cores)
Intel i7-4790K (8 Cores)
Intel i7-4771K (8 Cores)
Intel i7-3770K (8 Cores)
Intel i7-3770K (8 Cores)
Intel i7-3770K (8 Cores)
Intel i7-3770S (8 Cores)
Intel i7-3930K (12 Cores)
Nvidia GPUs:
GTX 780ti
GTX 780ti
GTX 780ti
GTX 780ti
GTX 780
GTX 690
GTX 690
AMD GPUs:
HD 7970 GBE
HD 7970 GBE
HD 7990
HD 7990
HD 7990
R9 295X2
R9 295X2
R9 295X2 - Location: Dallas, TX
Re: DAB & transparicy
JimF, Punchy,
I should clarify Point #2 in my original post that may have left you with an incorrect conclusion regarding the development environments, drivers, and other dependencies in order for F@H to advance. I'm not suggesting that PG be omniscient with respect to all the software development environments being used in tangential distributed computing projects. Specifically, PG must be aware of the dependencies that exist in the development tools, drivers and manufacturer support that limit the progress a given version of F@H can achieve. Without this information, they would have no basis whatsoever for developing a code release. To be as clear, I'm not asking for any new information only communication of information PG already has at their disposal when they make decisions about where to branch the project, including features, decrements, and bug fixes that are dependent on the advancement of underlying supporting code from other sources.
Once these specific dependencies related to F@H are exposed to the donor community, donors can then use that information to determine purchase decisions if they care to use it. Indeed, those decisions may very well be at the margin, but nevertheless it is information that factors into the calculus of any given individual donor's decision process.
In addition to the above, I'm certain that once communicated, this information could be used to rally the donor community to support PG in areas beyond "slots and watts". Recruiting the donor community to lobby the major hardware manufacturers to dedicate support to F@H functionality within their drivers and development tools to enable PG to issue code releases on a more consistent basis would be an excellent derivative of having a public F@H dependency list. Taking this further, imagine the influence strength PG would have on all other hardware manufacturers after just one event where this donor community banded together on the behalf of PG to get a manufacturer to definitively adopt F@H support as an on-going critical function set in their product lines. PG has the opportunity to wield a very large stick if they chose to exercise that power. However, they have to first put in place the mechanism to organize the donor community. In an almost surreal state of convenience, the information they already have in-hand, published to this community, is all it takes.
I'm not asking for PG to do any additional work on this topic other than to pluck an unpaid grad student (marketing major?) from a very large pool of candidates and assign them the product management responsibility of communicating to the donor community the status of information PG already has at hand. I've got to believe a job posting inside Stanford for this postion would be filled almost instantly, and probably could be filled as an internship position. While the argument of "lack of resources" may be valid, there are usually many ways around those limitations with enough creative thinking. And as well all know, creative thinking is certainly not lacking in an institution like PG or Stanford.
I should clarify Point #2 in my original post that may have left you with an incorrect conclusion regarding the development environments, drivers, and other dependencies in order for F@H to advance. I'm not suggesting that PG be omniscient with respect to all the software development environments being used in tangential distributed computing projects. Specifically, PG must be aware of the dependencies that exist in the development tools, drivers and manufacturer support that limit the progress a given version of F@H can achieve. Without this information, they would have no basis whatsoever for developing a code release. To be as clear, I'm not asking for any new information only communication of information PG already has at their disposal when they make decisions about where to branch the project, including features, decrements, and bug fixes that are dependent on the advancement of underlying supporting code from other sources.
Once these specific dependencies related to F@H are exposed to the donor community, donors can then use that information to determine purchase decisions if they care to use it. Indeed, those decisions may very well be at the margin, but nevertheless it is information that factors into the calculus of any given individual donor's decision process.
In addition to the above, I'm certain that once communicated, this information could be used to rally the donor community to support PG in areas beyond "slots and watts". Recruiting the donor community to lobby the major hardware manufacturers to dedicate support to F@H functionality within their drivers and development tools to enable PG to issue code releases on a more consistent basis would be an excellent derivative of having a public F@H dependency list. Taking this further, imagine the influence strength PG would have on all other hardware manufacturers after just one event where this donor community banded together on the behalf of PG to get a manufacturer to definitively adopt F@H support as an on-going critical function set in their product lines. PG has the opportunity to wield a very large stick if they chose to exercise that power. However, they have to first put in place the mechanism to organize the donor community. In an almost surreal state of convenience, the information they already have in-hand, published to this community, is all it takes.
I'm not asking for PG to do any additional work on this topic other than to pluck an unpaid grad student (marketing major?) from a very large pool of candidates and assign them the product management responsibility of communicating to the donor community the status of information PG already has at hand. I've got to believe a job posting inside Stanford for this postion would be filled almost instantly, and probably could be filled as an internship position. While the argument of "lack of resources" may be valid, there are usually many ways around those limitations with enough creative thinking. And as well all know, creative thinking is certainly not lacking in an institution like PG or Stanford.
Re: DAB & transparency
Yes, graduate students are a great resource that a university has available. But that touches on another resource that is not widely appreciated: Folding has enough work to do. That self-evident point is not always true for other projects. At the moment (I won't name names), several of the BOINC projects are very overloaded with users, especially those with AMD cards that don't have too many other places to go. Either the servers for those projects, or the scientists (or both) can't keep up. But PG never (thus far in my experience) has had that problem. They have enough talented researchers, both at Stanford and related institutions, to keep feeding them enough interesting projects to do. And it must be good work, based on the publications and notice they are getting in the scientific community. But organizational skill is the third leg (in addition to science and technology) that PG brings to the table. If they need additional input on that, it is fine with me, but I think they are in the best position to decide that. I can't tell them what proteins to work on either.
Re: DAB & transparency
The Null hypothesis is self evident.If they need additional input on that, it is fine with me, but I think they are in the best position to decide that.
Transparency and Accountability, the necessary foundation of any great endeavor!