Folding Forum

tear wrote:anger.on();

How unfortunate...

Thanks for your feedback. We can't improve something as complex as the MPI library in the SMP client overnight, but we are continuing to work on it and in time it will be improved. The complexity involved with the software is typical of "real" supercomputer applications, as it uses MPI. This is par for the course with any supercomputer application. Unfortunately, Windows is not a typical supercomputer OS and there issues with Windows and MPI.

By the way, if you feel like you can't judge the quality of Folding@home's science, I suggest you look to other 3rd parties to answer that, such as listed in the Awards section of our web site. We have received numerous work for the science produced from Folding@home. Perhaps that's the best judge of the significance of the work.

Improvement takes time, but I am confident it will happen. The GPU client is a good example of this: GPU2 is considerably easier to run than GPU1. We are also working to improve the graphics and GUI in the classic client. For those who want the most stable client, the classic console client is still the best bet.

Finally, I haven't heard any major problems with running the console client instead of running the SMP client, so that is still an alternative to consider (the original poster mentioned this as an alternative but never explained what was wrong with this alternative). The SMP client is definitely an experimental client and we've tried to make that clear, even by putting it on a separate download page. To try to make this more clear, we have added some additional text to this download page to emphasize this point. Donors who want as smooth an experience as possible should run the standard client.

smoking2000 wrote:

7im wrote:Sorry your patience has worn out. But the buggy nature of the client is mostly to do with MPICH, which is a third party software over which Stanford has no control.

What would you have Stanford do instead? Poorly written software? Sure, but not the software written by Stanford. Blame the 3rd party software.

Wrong. MPICH2 and DeinoMPI are Open Source software, Stanford can invest the developer time to fix the 3rd party code they're using. That's how it's done in the Open Source world. You're not dependant on the (single) supplier for fixes.

Whether they want and can make this develope time investment is another question, but they have the ability to fix the code their using, even the code they didn't write themselves.

I wasn't wrong. You are just splitting hairs. Pande Group has no more control over MPICH2 as they do Gromacs code. You're an open source zealot, so you should know that better than most.

And your second comment makes my point even more true. With little or no free time to help with open source, they can't help or control MPICH2 at the present time.

Let's hope the latest News post by Vijay (and the comments above) are a move in the right direction for the future of the SMP client.

Firestarter wrote:To everybody else: feel free to try and convince me otherwise

Why bother, you've already made up your mind.

There's always SETI. Go look for aliens!

He probably doesn't like the non-SMP console client because of the lower points per day.

wysiwyg_bill wrote:He probably doesn't like the non-SMP console client because of the lower points per day.

I should stress that the very reason we give more PPD in the SMP client is the challenges it takes to run it. One must choose to either run the without the hassles, but lower PPD (classic client) or more hassles, at least today, but higher PPD (the SMP client).

A fair day's work for a fair day's pay

sounds fair to me.

I got the 5.91 SMP client "running" on my quad-core, but after a couple of weeks and actually only completing TWO WUs (everything else was an EUE), I gave up and dropped back to running four single-core console clients. 5.92 wasn't an option because the change to DeinoMPI excluded 64-bit operating systems from running it.

I considered just dropping the whole program in frustration, but "slow WU's" are better than "no WU's". I have no illusions of ever being a super WU-cruncher (heck, one of the guys on my team is running a WU farm that heats his house! ) so the reduction in my capability is merely a delay in results.

Fadamor wrote:I got the 5.91 SMP client "running" on my quad-core, but after a couple of weeks and actually only completing TWO WUs (everything else was an EUE), I gave up...

My two Vista 64 boxes run SMP just fine, when installed outside of the C:\Program Files\ directory. I can't remember the last EUE from either one. So either you installed it in C:\Program Files\, or are overclocking too much, and/or don't have stable memory, or have a serious networking problem. Those are the only things that I can think of that would cause so many EUEs.

Most of those are not hard to test, so "give up" if you want, but with a little help from the rest of the users in this forum, we can usually get SMP working on any supported hardware.

And this may explain why you have expressed a distaste for SMP and Stanford in that other thread. Don't worry, we'll get you fixed up.

I didn't know about that whole "run outside of c:\program files\..." bit. I'll do that. Why does it make a difference? Is it because it puts it in the 32 bit program files directory?

Vista adds extra protection against viruses, malware, etc. to that directory tree. And the fah client, being a simple DOS like application, was written well before Vista came around. But that also means Vista sees FAH as a potential threat, and stops the client from adding new executable files (like a virus would) but that stops fah from downloading the fahcores, which are executable files.

Firestarter,
I understand your frustration. More than once have I felt like I was banging my head against a brick wall trying to get a 2665 to finish. But the first two lines of the summary from research paper #53 makes it all worthwhile to me. (too bad I didn't understand anything after that)

SUMMARY: This paper describes the first set of results generated using the SMP clients. The main advantage of using SMP for these sorts of calculations is that the amount of computation that one client can do is several times larger than the traditional clients.

On a personal note:

Firestarter wrote:or call me names.

Firestarter seems like a nice name so I will just call you that.

Okay, that's enough. He can either come back or not. Thread closed. If he wants to comment again, he can PM us to reopen the thread.