Folding@home

NVIDIA core upgrade to 1.06

We're rolling out an automatic core upgrade for GPU2/NVIDIA clients to v1.06.  Please post in the forum if you're having any new problems with your GPU2 client after this (although the 1.06 core has been tested very thoroughly so far).

Assignment server code upgrade

We've upgraded our code in our main Assignment server to improve some load balancing issues.  This upgrade also has new code for how the url for new core downloads are sent.  We have tested this code on less important AS's first, but if you start seeing problems with core downloads, please make a post in our main forum (http://foldingforum.org), ideally with some of the log with -verbosity 9 to show the core download url.

Folding@home's End User License Agreement (EULA) and why it's there

There's been some recent discussion of aspects of Folding@home's EULA and what constitutes a violation of the EULA.  One key issue is whether donors (end users of the FAH software) can make modifications to the code in order to make enhancements, such as multi-gpu support for NVIDIA.  While such modifications may be made with the very best of intentions, these modifications do not go through our QA (either at Stanford or our relevant partners such as NVIDIA, ATI, or Sony).  This is a big problem with 3rd party client modifications is that even very subtle modifications can create problems for the science involved.  Since there's no way for donors to QA end user modifications, we cannot support their use and must remind everyone that any modifications to any of the client binaries is a true EULA violation.

The bottom line is that even though some modifications may be done with the very best of intentions (eg to help the Folding@home project, never to hurt it), we can't tell whether those intentions translate into true help for the project without QA.  Also, perhaps more importantly, it's hard to say that "some violations of our EULA" or "some modifications to the client code" are ok.  There's no way to know whether something is ok until it goes through QA.

Finally, it's been my experience with FAH that donors can often have very good ideas on how to improve the FAH software.  I have a suggestion as an alternative to 3rd party releases of client modifications.  Please go to the folding community forum (http://foldingforum.org) and make a post with the jist of your idea and someone from the FAH development team will get in touch with you.  If we're already working to QA a fix for that type of change (eg multi-gpu support), it would make more sense for us to finish our existing QA than to start fresh with some other solution (since QA of a new approach would delay the release of that feature).  We are always looking for beta testers for new functionality and so that's another way donors can help the project and get access to early features.

For example, we are actively working on several key issues right now on the GPU2/NVIDIA client, including multi-gpu support and better desktop performance, and hope to have something to release very soon (days timescale, assuming that the fixes get past QA without problems).  If you're interested in beta testing some of these features, please make a post in the forum.

I wanted to thank everyone for their help to improve FAH clients and the FAH experience in general and hope we can work together to get the needed fixes in.  We are grateful for all the help we get from FAH donors.  However, I hope everyone can appreciate the need for QA, especially radically new and complex clients like GPU2, and that we can find a way to work together to get the fixes needed.

GPU2 update

The GPU2 client has been out for a while now for our newest platform, NVIDIA, and I wanted to give an update.  We're making great progress on several fronts of the beta testing of this client, with improvements to the CPU utilization and visualization (which currently is pretty much broken) coming soon.  We are also working to support multi-gpu configurations.  These are our highest non-science priorities.  On the science-side, we're scrubbing the GPU clients to make sure the results make sense.  GPU programming is challenging for many reasons, especially due to reduced precision and the complexity of using lots of threads in flight, and so it's important to make sure the results are accurate.  So far, the results look promising.  Once the GPU2 cores are  completely validated and these client issues  are addressed, we'll take the client out of beta and make a push to get an even greater adoption of this new client platform.

KNOWN ISSUES FOR GPU2/NVIDIA

Viewer doesn't work (coming soon).  This will require a core upgrade, which is in the works.

GTX280 driver version.  For pre-GTX280 cards, we recommend version 174.55 of the CUDA driver.   We recommend 177.35 for GTX cards.

CPU usage can be strange (we're looking into this).  The CPU utilization can spike on certain machines.  We have an idea for what's the issue and Scott LeGrand at NVIDIA is working on a fix.

UNSTABLE_MACHINE error if too many EUE's (not really a bad thing -- a true feature of the client).  If you see this error in your client log, it means that there is some problem with your configuration.

GPU2/NVIDIA auto-core upgrade

We've forced a core upgrade to version 1.05 for GPU2/NVIDIA.  We did this since there is important new code there.  In particular, there's code that will better handle unstable or incorrectly configured machines.  This core now generates an UNSTABLE_MACHINE error and the 6.12beta6 client will trap this error, leading to a 24 hour sleep for the client if 5 such UNSTABLE_MACHINE errors are reached.

If you are having problems running your client after this forced core upgrade, it most likely means that there's a problem with the client installation, most likely with startup aliases.  If this is the case, please check out the FAQ and in particular note that the Start In and Target directories have to be different:

In Windows XP:
Target: "C:\Program Files\Folding@home\Folding@home-gpu\[email protected]" -verbosity 9
(or whatever flags you use instead of -verbosity 9)
Start in: "C:\Documents and Settings\<your_windows_username>\Application Data\Folding@home-gpu\"

In Windows Vista:
Target: "C:\Program Files (x86)\Folding@home\Folding@home-gpu\[email protected]" -verbosity 9
(or whatever flags you use instead of -verbosity 9)
Start in: "C:\Users\<your_windows_username>\AppData\Roaming\Folding@home-gpu\"

Please see our FAQ for more details:
http://folding.stanford.edu/English/FAQ-NVIDIA

GPU2 client 6.12beta6 on high performance client download page

Since the GPU2 client 6.12beta6 is behaving well, we've put it on our main download page:

http://folding.stanford.edu/English/DownloadWinOther

We'll post updates there as they work their way through QA.

Forum under a heavy load

Due to the new GPU2/NVIDIA client release today, we got cited on Digg, which sent all the traffic to the forum (which can't take too heavy of a load), instead of say http://folding.stanford.edu (which can).  We're working
 with our forum Internet service provider to work this out ASAP.

GPU2 beta client for NVIDIA now released

We've started our open beta release.  See the post here
http://foldingforum.org/viewtopic.php?f=42&t=3188
We will put it on our main download page when it gets a bit further through the beta QA process.  This is an early release.

Note that this is still a very early beta and there's lots to fix.  In particular, we need to correct some issues with the visualization and the EUE handling.  However, we've got that in our roadmap and should be rolling that out over the next few weeks or so (hopefully sooner, but it may be longer depending on how tricky these bugs are to handle).

If this release looks to run well for most people, we'll put it on our main download page.

GPU2 client for NVIDIA

Please go to our forum (http://foldingforum.org) for up to the second details of the new client.  I'll make a post here when there is more to say.

What does the SMP core do?

Our SMP core is very different than the way other distributed computing projects handle multi-core CPU's, and I thought it might be interesting for the FAH community to hear about the differences, pro and con.  As I think most people interested in computers know, Moore's law stating that the transistor count in CPUs will double every 1.5 years has continued for decades.  Most people think of Moore's law in terms of the speed of CPU's, but this isn't what Moore originally had in mind.  In the past, more transistors have lead to greater CPU speeds, but that has essentially ended (at least for traditional CPU's) a few years ago. 

But if Moore's law is still marching along (as it is), what do all those transistors do?  Over the last few years, more transistors have translated into more CPU cores, i.e. more CPUs on a chip.  While this is not what we wanted, this is perhaps not necessarily a disaster, if one can use these multiple CPUs to get faster calculations.  If we simply do more calculations (i.e. multiple Work Units, or WU's, simultaneously) not faster calculations (a WU completed in less time), distributed computers will run into the same problems that face supercomputers: how to scale to lots and lots of processors -- i.e. how can we use all these processors to do a calculation faster over all.

In FAH, we've taken a different approach to multi-core CPUs.  Instead of just doing more WU's (eg doing 8 WU's simultaneously), we are applying methods to do a single WU faster.  This is typically much more valuable to a scientific project and it's important to us.  However, it comes with new challenges.  Getting a calculation to scale to lots of cores can be a challenge, as well as running complex multi-core calculations originally meant for supercomputers on operating systems not meant for this (eg Windows).

Right now, our SMP client seems to be running fairly well under Linux and OSX -- operating systems based on UNIX, as is found on supercomputers.  We use a standard supercomputing library (MPI) to run these WU's and MPI behaves well on Unix-based machine.  MPI does not run well on Windows and we've been running into problems there.  However, as Windows MPI implementations mature, our SMP/Windows app will behave better.  Along the way, we also have a few tricks up our sleeve which may help as well.  However, if we can't get it to run as well as we'd like on Windows, we may choose to overhaul the whole code, as we did with the GPU1 client (which was really hard to run).

We're very excited about what the SMP client has been able to do so far.  One of our recent papers (#53 in our papers web site http://folding.stanford.edu/English/Papers) would have been impossible without the SMP client and represents a landmark calculation in the simulation of protein folding.  We're looking forward to more exciting results like that in the years to come!