Folding Forum

smokejumper wrote:well i have been a member of a folding team for about 6 months now. and the biggest reason i can see for not folding is the total lack of support when someone has issues getting things correctly setup. So i am the point of frustration that I am actually thinking about giving it up. I would think more people here would be slightly more serious about what we are doing. well I hope things get better around here or i am sure I wont be the only one ready to give up.

This is somewhat where teams come into play. Join a good team that can give support and help you get up and running. I post on my teams forums, before posting here when I have a problem.

Nice work John Naylor! I posted a link to your post to WCG forum. Hope you keep updating this in the future as well!

cheers
Mika

codysluder wrote:I second that.

BOINC is easy to use, and so is the FAH classic client. You won't find any "user abuse" if you use either of them, but you also will not use your equipment to the max. In time, the FAH SMP and GPU clients will mature and be easier to use. In time, clients like them will be added to BOINC.

There are some excellent reasons why some people should run BOINC and some excellent reasons why other people should run FAH. We encourage you to take all the facts into consideration and make a decision that works for you.

Thank you for your forthright comments on FAH. I'm sure Stanford will take them into consideration as they develop future versions of FAH.

As I see it, F@H is a tweaker's toy, while BOINC just gets the job done. Folding@Home has made no attempt to be a serious scientific tool for anything other than computer science or psychology. There are teams out there that are screaming and or begging for people to join them, and a lot of people do. Have you checked the retention rate for F@H vs BOINC? My own team has hundreds of members but less than twenty active, the other quit. Some claimed it was the cost of electricity, more than a few claimed that it was such a pain to setup. I know that every project like this has a high drop out rate, but F@H has such a low retention rate, a reasonable person would ask why.

You mentioned that “clients like them will be added to BOINC.” I would like to point out that F@H was kicked out of BOINC project. Have you asked yourself or anyone else why? I did. I was told (by more than one person involved with BONIC development) that BOINC no longer supports F@H due to the poor quality of the F@H sub-clients. BOINC currently hosts eight biological research projects, four of which seem similar in description to F@H’S goals.

You said: “In time, the FAH SMP and GPU clients will mature and be easier to use." How long? It took Seti@Home less than five years to have an easy to use client that could use everything your computer could give, you have not even updated your client since my last post more than six months ago. You are still dealing with the same bugs, shoot, both the GPU and CPU clients’ still use the same configuration files which means they try to use the same Machine ID even if you install and configure them separately!

In the long run, and if nothing changes the perceptions and attitudes of the leadership of the F@H project this project we be used as an example of how a distributive computing project can fail. Folding@Home as it currently exists appeals to the geeks that like to tweak an application to get maximum performance out of it.

Don’t get me wrong, I fully support the goals of F@H. I am frustrated at the lengths I need to go through to get it working reasonably well on my system. I have spent hours trying to get that extra point or two out of my machines and even more hours trying to get the GPU and CPU clients to work without stepping on each other. Now, with my crossfire GPUs I find that I need to install yet another client (that will conflict on startup) because F@H is the ONLY project of it’s type that does not have native support for SLI or CrossFire.
Yeah, that makes it easy to recruit and keep volunteers. This is what upsets me so much, there is no logical reason for all these failures. I would think that almost any competent programming student could write a wrapper application in a month or two and have it work better than you have at this point.

kzaske wrote:

codysluder wrote:I second that.

BOINC is easy to use, and so is the FAH classic client. You won't find any "user abuse" if you use either of them, but you also will not use your equipment to the max. In time, the FAH SMP and GPU clients will mature and be easier to use. In time, clients like them will be added to BOINC.

There are some excellent reasons why some people should run BOINC and some excellent reasons why other people should run FAH. We encourage you to take all the facts into consideration and make a decision that works for you.

Thank you for your forthright comments on FAH. I'm sure Stanford will take them into consideration as they develop future versions of FAH.

As I see it, F@H is a tweaker's toy, while BOINC just gets the job done. Folding@Home has made no attempt to be a serious scientific tool for anything other than computer science or psychology. There are teams out there that are screaming and or begging for people to join them, and a lot of people do. Have you checked the retention rate for F@H vs BOINC? My own team has hundreds of members but less than twenty active, the other quit. Some claimed it was the cost of electricity, more than a few claimed that it was such a pain to setup. I know that every project like this has a high drop out rate, but F@H has such a low retention rate, a reasonable person would ask why.

You mentioned that “clients like them will be added to BOINC.” I would like to point out that F@H was kicked out of BOINC project. Have you asked yourself or anyone else why? I did. I was told (by more than one person involved with BONIC development) that BOINC no longer supports F@H due to the poor quality of the F@H sub-clients. BOINC currently hosts eight biological research projects, four of which seem similar in description to F@H’S goals.

You said: “In time, the FAH SMP and GPU clients will mature and be easier to use." How long? It took Seti@Home less than five years to have an easy to use client that could use everything your computer could give, you have not even updated your client since my last post more than six months ago. You are still dealing with the same bugs, shoot, both the GPU and CPU clients’ still use the same configuration files which means they try to use the same Machine ID even if you install and configure them separately!

In the long run, and if nothing changes the perceptions and attitudes of the leadership of the F@H project this project we be used as an example of how a distributive computing project can fail. Folding@Home as it currently exists appeals to the geeks that like to tweak an application to get maximum performance out of it.

Don’t get me wrong, I fully support the goals of F@H. I am frustrated at the lengths I need to go through to get it working reasonably well on my system. I have spent hours trying to get that extra point or two out of my machines and even more hours trying to get the GPU and CPU clients to work without stepping on each other. Now, with my crossfire GPUs I find that I need to install yet another client (that will conflict on startup) because F@H is the ONLY project of it’s type that does not have native support for SLI or CrossFire.
Yeah, that makes it easy to recruit and keep volunteers. This is what upsets me so much, there is no logical reason for all these failures. I would think that almost any competent programming student could write a wrapper application in a month or two and have it work better than you have at this point.

I know this doesn't really answer your questions but there is a v7 client in development which should be out sometime this year, which is a ground-up rewrite of the client software by a professional coder rather than by scientists who would rather spend their time improving the science code than the client code. Progress on this has probably been slowed down by issues with the work server code and various other parts of Folding@home that are being rewritten by the same developer, but the Pande Group have not yet said anything to change the expectation that this new client will be out this year.

SETI@home improved much faster as it is an open-source project so anyone could try to improve the code, but the Pande Group have decided that for better or for worse they will keep the application code closed source. This means that client development has to compete for the scientists' time with the other duties necessary in running a project. As the project is in a transition period, with transitions from SMP -> SMP2, GPU2 -> GPU3, v3 and v4 to v5 server code, and various other background changes, progress may appear to be slow but it is happening.

John Naylor wrote:...there is a v7 client in development which should be out sometime this year, which is a ground-up rewrite of the client software by a professional coder rather than by scientists who would rather spend their time improving the science code than the client code.

AWESOME, I know what I am getting this Christmas Hope there won't be any more delays

John Naylor wrote:I know this doesn't really answer your questions but there is a v7 client in development which should be out sometime this year, which is a ground-up rewrite of the client software by a professional coder rather than by scientists who would rather spend their time improving the science code than the client code. Progress on this has probably been slowed down by issues with the work server code and various other parts of Folding@home that are being rewritten by the same developer, but the Pande Group have not yet said anything to change the expectation that this new client will be out this year.

Apart from the clients being user friendly, the f@h project seriously needs a way to build competition and show off donors' work. I just took a look at some BOINC projects that seemed close to my interests and most of them had -other than points and certificates- counters of the numbers of WUs completed today, which team was most active, which user etc. Relationships with donors is a must when it comes to big-scale projects and I believe that Pande Team has left that part to luck and randomness.

Someone around here mentioned medals about top users and the response was that teams are responsible for those, not Stanford. Excuse me, but how much time can drawing a simple medal take? Heck, even members could draw some of them and we could vote on the best, through a poll. Just an example of some small actions that can give f@h the missing edge it needs to improve.

When I started my team at a forum of more than 200 active members, some people asked me if they could get more knowledge on the theory of protein folding via the project. Nope, just some basic wiki. Others found the installing instructions too complicated to waste their time on. Others were plainly suspicious. Others left the project in two months, because they lost interest. The result is that today only 3 people in my team still fold for Stanford. A long, detailed FAQ that I wrote doesn't help. Nor an animated image I made. For when they enter the project's main site, they face a barrier of "user-unfriendliness".

John Naylor wrote:I know this doesn't really answer your questions but there is a v7 client in development which should be out sometime this year, which is a ground-up rewrite of the client software by a professional coder rather than by scientists who would rather spend their time improving the science code than the client code. Progress on this has probably been slowed down by issues with the work server code and various other parts of Folding@home that are being rewritten by the same developer, but the Pande Group have not yet said anything to change the expectation that this new client will be out this year.

SETI@home improved much faster as it is an open-source project so anyone could try to improve the code, but the Pande Group have decided that for better or for worse they will keep the application code closed source. This means that client development has to compete for the scientists' time with the other duties necessary in running a project. As the project is in a transition period, with transitions from SMP -> SMP2, GPU2 -> GPU3, v3 and v4 to v5 server code, and various other background changes, progress may appear to be slow but it is happening.

I am glad to hear that a new client is being worked on. I really hope that user friendliness is a primary focus. I am sure that I am not alone in hoping that F@H becomes a shining example of how to turn around a project on the brink of failure. I know there is a lot of work to do, the primary web site needs to be rebuilt, the wiki needs; well it just needs way too much to be covered here then there are the client installers. The current system of installers is very confusing and will easily put off most people.

What can be done to make F@H user friendly? F@H needs a paradigm shift. From install to working folder needs to be as easy as possible for every person that would like to donate clock cycles. How about using a web-stub as the first step? The stub, based on Java or Flash would detect the OS and select the correct installer; Mac, Linux, Windows 64bit or Windows 32bit. The installer should detect the processor type and number of cores, GPU type (NVIDIA, ATI or unknown) and the number of GPUs available and install the applicable clients and launcher. The launcher would be a single application that loads each applicable client, manages the work units and configures each client so that the customer (volunteer) does not see an error message. Optimally the launcher would also allow the user to install and configure a higher performance client with the applicable warnings concerning system load and responsiveness slowdowns. If you programmer is good, he or she should be able to make the launcher adjust the CPU/GPU load in response to what the user is doing so that the user would experience only a slight non-responsiveness while the clients are running, I am not sure how difficult that would be.

I know the Pande Group wants to focus on science but user friendliness needs to be the focus of your programmer for this new client. In short, what good is good science if the complexities of that science are shoved in the face of volunteers to the point where setting up and maintaining the individual clients takes more time than the volunteer is willing to give.
As for rewards, yeah some reward would be nice, but I have no clue what to do in that respect. I am a data person not a “people person.” As my boss puts it, I watch the heard move as a whole, not the individual cows.

Rebuilding the server software is not an easy task either. I wish your developer luck and lots of skill. Looking forward to the new client.

I think the problem is that all the F@H stuff is closed source. There are many skilled people who want to help and have lots of time right now (ie, completely out of work, not looking : me) and could help a bunch. Keep the science tight, but open source everything else. My whole career has been data management for large companies. The amount of data in the stats is small fry compared to the amount of stuff in companies repositories. There is no excuse for non-realtime reporting. Follow the rule of companies where money is king : if you're not good at it, outsource it.

I don't know how the current clients work. An approach to let volunteers work on the client side would be to extract all the science and results submission into an .so or .dll and provide an API with callbacks to let client developers do whatever they think is cool and easy to install.

David, I think you just hit the nail on the head. The fact is these researchers are concerned with science, not user friendliness and they are not concerned with the human motivations, specifically competitiveness. While I don’t see real-time reporting as a huge issue, I also acknowledge that it is an issue, especially for team managers.

My specialty is customer support processes (with a large hardware/software company) where I review issues as reported by customers and try to identify a root cause and develop documents that would allow customers to address and correct the issue themselves.

In the real world (non-academia) this project would be classified as a disaster. The entire management staff would have been fired a long time ago and the project scrapped or relaunched.

kzaske wrote:As I see it, F@H is a tweaker's toy, while BOINC just gets the job done. Folding@Home has made no attempt to be a serious scientific tool for anything other than computer science or psychology. There are teams out there that are screaming and or begging for people to join them, and a lot of people do. Have you checked the retention rate for F@H vs BOINC? My own team has hundreds of members but less than twenty active, the other quit. Some claimed it was the cost of electricity, more than a few claimed that it was such a pain to setup. I know that every project like this has a high drop out rate, but F@H has such a low retention rate, a reasonable person would ask why.

You have some valid points of view, but are a little biased towards customer support having come from that field. No academic project really excels at customer support. And I see things a little differently, having come from SETI I, and early Boinc development on SETI II, and having been with F@h a number of years now. Fah is both a tweakers toy, and gets the job done. If you want simple, install the CPU client, set it and forget it. If you want high performance, fah can do that too. Boinc doesn't offer that high performance option.

I also have to disagree with that serious attempt comment. Fah, being the world record holder for the most powerful distributed computing project, is always a serious contender. They have chosen to do one type of molecular simulation, and do it very well. Where as Boinc has tried to be some thing to all people, Fah has been the 1 best thing for a select group of people. Boinc is written by committee, with a lowest common denominator, like a family sedan. Fah was written for performance, like a race car. Family sedans do many things in an average manner. Race cars only do a few things, but do them much better than a sedan.

As for retention stats, anyone can claim anything, because that isn't tracked anywhere. So you can't really claim the high ground for Boinc, can you? And you said yourself, most quitters cited the cost of electricity. So how is that any different for fah vs. boinc?

kzaske wrote:You mentioned that “clients like them will be added to BOINC.” I would like to point out that F@H was kicked out of BOINC project. Have you asked yourself or anyone else why? I did. I was told (by more than one person involved with BONIC development) that BOINC no longer supports F@H due to the poor quality of the F@H sub-clients. BOINC currently hosts eight biological research projects, four of which seem similar in description to F@H’S goals.

Fah was not kicked out of Boinc. Fah NEVER joined boinc, so it couldn't get kicked out. Yes, there was an attempt to develop a joint project, but both Boinc and fah clients fell short. Neither client type had enough ability to be compatible with the other. Boinc lacked many features that fah needed, and fah lacked features that Boinc needed. I was around for the development, so my knowledge is first hand, and I'll refrain from specific finger pointing. Your knowledge on the topic seems only to be biased hearsay. Sorry.

kzaske wrote:You said: “In time, the FAH SMP and GPU clients will mature and be easier to use." How long? It took Seti@Home less than five years to have an easy to use client that could use everything your computer could give, you have not even updated your client since my last post more than six months ago. You are still dealing with the same bugs, shoot, both the GPU and CPU clients’ still use the same configuration files which means they try to use the same Machine ID even if you install and configure them separately!

Ah, yes, that client has not been updated in a while, but you are completely missing the point. The client is the framework, like Boinc. The fahcores do all of the processing, and new fahcores are released many times a year. I've seen 4 new fahcores in as many weeks. As for how long it will take the SMP and GPU clients to mature, I'll let you know in 2 more years, when both of those clients finally reach the 5 year mark. Boinc wasn't any better than fah a couple years in to its development either. I was there for that as well.

And that last part about using the same config files isn't really true. The fah client only uses the config file in the folder where the client gets installed. If you follow the install guides for each client, that never happens. Clients get installed in separate directories. I suppose if someone screws up a Boinc install, it wouldn't work much better either.

kzaske wrote:In the long run, and if nothing changes the perceptions and attitudes of the leadership of the F@H project this project we be used as an example of how a distributive computing project can fail. Folding@Home as it currently exists appeals to the geeks that like to tweak an application to get maximum performance out of it.

Yes, I suppose anything can fail. And yet no other project has succeeded as well as FAH. From world record holder, to first ever GPU client, to first ever PS3 client, to first ever true SMP client... shall I go on? Sorry, but you wouldn't scrap a world record holding project, not even in a corporate world. And just like in a corporate world, when you need programming help or improvements, you hire a professional. And fah has hired a professional software development firm to rewrite the client and server code from the ground up for the next version. Your suggestions do not fall on deaf ears.

And yes, fah currently has some rough edges, but not all edges are rough. That's what happens when you blaze new trails with new clients on new types of hardware. If you want smooth, feel free to follow along on the path that Fah plows while riding on the comfy coat tails of Boinc.

kzaske wrote:Don’t get me wrong, I fully support the goals of F@H. I am frustrated at the lengths I need to go through to get it working reasonably well on my system. I have spent hours trying to get that extra point or two out of my machines and even more hours trying to get the GPU and CPU clients to work without stepping on each other. Now, with my crossfire GPUs I find that I need to install yet another client (that will conflict on startup) because F@H is the ONLY project of it’s type that does not have native support for SLI or CrossFire.
Yeah, that makes it easy to recruit and keep volunteers. This is what upsets me so much, there is no logical reason for all these failures. I would think that almost any competent programming student could write a wrapper application in a month or two and have it work better than you have at this point.

I am glad to hear you fully support fah, as do I. I too get frustrated at times. I have expressed many strong criticisms in the past, similar to your own. Much of what you say are not new complaints. But as a supporter, we try to work thorough the difficulties, and contribute to the success of the project while they try to improve it. And by the way, the latest GPU fah client (and latest NV and ATI drivers) don't care about SLI or Crossfire. And for reference, NO other DC project uses SLI or Crossfire to do dual GPU processing, but then neither does fah, so that's beside the point.

If you are not up to the challenge of running a high performance client, then I recommend you follow the warnings on the High Performance client page. If you don't have the technical prowess, and/or the patience and tolerance to deal with early developmental clients, then by all means, run the easier CPU clients, or easier boinc projects. Naturally we'd prefer you give your all to fah, but we understand that isn't for everyone, and wish everyone a happy and less stressful computing experience.

And we'd be more than willing to help you sort out any fah installation issues you may run in to.

7im wrote:
You have some valid points of view, but are a little biased towards customer support having come from that field. No academic project really excels at customer support. And I see things a little differently, having come from SETI I, and early Boinc development on SETI II, and having been with F@h a number of years now. Fah is both a tweakers toy, and gets the job done. If you want simple, install the CPU client, set it and forget it. If you want high performance, fah can do that too. Boinc doesn't offer that high performance option.

last I heard, the SETI project and a few other BOINC projects have GPU clients. also, the BOINC client does actually scale to multi processor or cores by spawning a uniprocessor work unit core and setting its processor affinity for each physically available cpu/core, so it isn't really under performing much by comparison.

theteofscuba wrote: last I heard, the SETI project and a few other BOINC projects have GPU clients. also, the BOINC client does actually scale to multi processor or cores by spawning a uniprocessor work unit core and setting its processor affinity for each physically available cpu/core, so it isn't really under performing much by comparison.

Yep, but those GPU clients came years after FAH blazed that trail. But they still don't push those GPUs to their processing limits like fah does.

And no, spawing multiple single processes to fold multiple individual work units is no where near as powerful as combining multiple processes to pound out the work in a much larger single work unit. If many individual cores were better, we'd have no need for clustered super-computers.

Again, Boinc comes in 2nd place for performance. Sorry.

7im wrote: If you want smooth, feel free to follow along on the path that Fah plows while riding on the comfy coat tails of Boinc.

1. First OpenCL support http://lunatics.kwsn.net/index.php?topic=857.msg26010

2. 64 bit support http://boincstats.com/forum/forum_thread.php?id=1774

3. running different projects and multiple tasks on the same gpu (milkyway & collatz most common)

7im wrote: But they still don't push those GPUs to their processing limits like fah does.

1. are your ATI cards burning hot while running FAH?

2. it would be interesting to see some temps on the same NVIDIA hardware while running milkyway and fah

7im wrote: And no, spawing multiple single processes to fold multiple individual work units is no where near as powerful as combining multiple processes to pound out the work in a much larger single work unit.

True, cpdn could really use this

From my point of view, in the end, it's all about open-source and closed-source.
I'm looking at symbian vs android platform, feel free to correct me if I'm wrong.
Up until las year, symbian was nr.1 mobile software platform worldwide.
When android started showing it's muscles, symbian became ...well ...open-source.

I will continue to support fah, wait for gpu3, be amazed of it's optimization and performance up until (probably this year) gpugrid (ATI) or wcg (ATI /NVIDIA) release their gpu client .
After that I'll run collatz or einstein on lower gpu hardware.

I'll concede #1. It would be silly to assume fah could be #1 in every category. Good point, although we're not very far behind in this. You might also note who is developing OpenMM.

#2 is doesn't mean much for fah. The 32 bit fah client runs just as fast. 64 bit support does nothing for speed. Sorry.

#3 is a nice feature, but unnecessary for fah. And you can run fah and Boinc side by side if you want, so again, adding that feature to fah has little benefit to fah.

As to comparing GPU temps, that's a very good question. I know how smokin' hot my GPU1 client ran, but I haven't run the GPU2 client on ATI hardware. But I know the GPU2 smokes on NV hardware. A recent fah forum thread about the v195.x NV driver bug not running the fan above 80% having caused some concerns might be a good indication. If you have to run your fan above 80%, you're clearly using the board well.

Clearly fah has a lot of room for improvement other places, like ease of install, keeping the documentation up to date, etc. But scientifically, it's hard to beat.

7im wrote:
#3 is a nice feature, but unnecessary for fah. And you can run fah and Boinc side by side if you want, so again, adding that feature to fah has little benefit to fah.

One of the nice things of BOINC is that it allows you to crunch for multiple projects when you can't decide which single project to donate to, not that it tries to run more than one project at the same time more than the hardware can afford, it doesn't.

users sign up for multiple projects and BOINC will cycle through each project you crunch for in round robin style fashion so as to not spend too much time on any one single project.

it could be a bennefit to FAH if FAH was ported to BOINC. There are probably plenty of people out there who would add FAH to their list of projects to donate to in addition to whatever BOINC projects they already contribute to. It just seems a lot easier to recruit those BOINC users to FAH using BOINC, than to convince them to abandon BOINC for exclusive FAH contribution running the independent, stand-alone FAH client.

I mean run FAH both independently via the v6 v7 client, and via BOINC at the same time.