Folding Forum

Hi,

While I do most of the FAH work from my PS3, I'm considering using my PC for further processing overnight. The PC has a single 3.0 GHz P4 processor, 2 GB of RAM, a ATI HD-3850 (AGP) graphics card and running WinXP SP2.

As best as I have been able to determine I have two choices, the Windows XP client (System tray) or the GPU1 client. Can't/won't install the GPU2 client.

Based on the above PC hardware specs, which client should I install?

Thanks.

If letting it run 24/7, then the GPU2 client is your best bet for most production. It is the only GPU client for your type of video card. GPU1 only ran on X19xx series cards and lower. And technically, you could run both a single CPU and GPU client if HT were enabled.

If the machine is only folding part time, the GPU2 client may not make the deadlines, so a single CPU client for XP is the best option.

I work on the computer daily, so it would not be possible to run a client 24/7 (maybe on weekends). I looked at the requirements for GPU2 and it needs .NET, which I will not install. Which is why I originally thought the GPU1 client was at least an option. In that case, it's the Windows System Tray client that I should install.

The CPU does have Hyper-Threading and it is enabled. However, unless the Windows System Tray client is HT aware, won't that then mean that the Windows Client will only see half the CPU?

Thanks.

For the CPU client, attempting to run 2 copies on a single HT core is not recommended by the project managers. Doing so will not double your output.

Without .net, your remaining option is the CPU client. Running the console version as a Service is the cleanest, easiest way to do that.

Tynat wrote:I work on the computer daily, so it would not be possible to run a client 24/7 (maybe on weekends).

That is a misconception. The fah CPU client is designed to run in the background, and to only use CPU cycles not used by other programs. Fah runs at the lowest level of priority, so all other programs get all of the CPU power they require. Most people run fah 24/7 and do not notice any performance impact. Fah is running on the computer I am at right now.

7im; you mentioned, "If the machine is only folding part time, the GPU2 client may not make the deadlines". My 24/7 comment was based on that, and not on the priority level of the client itself. Sorry for any confusion I may have caused.

jrweiss; It's unfortunate that .NET is a requirement for the GPU2 version of the client. I had considered the console client, but I'm not that swift when it comes to CLI programs and their switches. So, I have opted to install the Windows System Tray client (v6.23).

Being that this is the first time I have used the Windows System Tray client, I have a few observations I would like to share. Maybe in time it will help others.

1) The installation did not work as I had seen in a video showing the installation procedure. In the video it shows that you are allowed to pick your install directory and where you would like to place the shortcuts. This option is no longer available in the current version and there should be a "Custom" install option (as there is with most programs). This is particularly annoying for where the shortcuts get placed. I've moved them to a better location, but should I need to uninstall or update the client, I will likely need to remember to put them back. Otherwise, there will be duplications.

2) Once the installation was complete, my Firewall alerted me about "Folding@home.exe" wanting Internet access and I have granted it permission. No biggie.

3) After starting the client for the first time, I entered the required configuration information (User name, team name, etc).

4) However, it appears to be doing absolutely nothing. Hovering the mouse over the System Tray says, "Attempting to get work packet". The last attempt in the Logfile says the following:

[00:03:39] + Attempting to get work packet
[00:03:39] - Connecting to assignment server
[00:03:40] - Successful: assigned to (128.59.74.4).
[00:03:40] + News From Folding@Home: Welcome to Folding@Home
[00:03:40] Loaded queue successfully.
[00:03:40] + Could not connect to Work Server
[00:03:40] - Attempt #10 to get work failed, and no other work to do.Waiting before retry.

The typos in line [00:03:40] is that of the FAH client. Lord knows I make enough of them on my own that I don't need help.

The header in the log says, "Opening Log file [February 13 23:19:53 UTC]". As I write this, the time is 00:45:15 UTC and for nearly 1½ hours the client appears to be doing nothing. Not off to a great start.

5) I can't think of a good reason that every time the Display Viewer is selected that a new instance of the Display Viewer appears. Once the Display Viewer is on the screen, selecting it again should bring it to focus (such as when it's hidden behind other windows), not create another Display Viewer.

I'd like to suggest a change in the way the Display Viewer works and since the names of the sub-forums seem a bit ambiguous to me, could you please tell me which sub-forum I should post my concerns in, knowing that I'm running the Windows System Tray client (v6.23)?

Thanks for all the replies.

Closed the program down, ate dinner and then restarted client. Here's the latest from the log:

[04:14:21] + Attempting to get work packet
[04:14:21] - Connecting to assignment server
[04:14:21] - Successful: assigned to (171.67.108.13).
[04:14:21] + News From Folding@Home: Welcome to Folding@Home
[04:14:21] Loaded queue successfully.
[04:14:22] + Could not get Work unit data from Work Server
[04:14:22] - Attempt #12 to get work failed, and no other work to do.Waiting before retry.

The current time is 04:16:41 UTC. If I go all the way back to the beginning of the log file when I started the client the very first time, that is February 13 23:09:25 UTC, it has now been more than 5 hours and still nothing.

This is very discouraging.

The viewer program is a work in progress, and obviously still needs a lot of work (and is separate from the fah client).

Not sure why your client can't get work... Besides entering a user name and team number, did you change any of the other default settings in the client setup?

Not related to the CPU client, but what's wrong with .NET?

And what specific typos?

Yeah, the Display Viewer is most definitely a work in progress. It has no self awareness and it should. That is particularly important considering how much processing power is required for it to render the display. The more Display Viewers that are open, the more overloaded the system becomes and that's bad.

Besides entering a user name and a team number under the User tab, I also changed the Checkpointing Frequency to a lower number in the Advanced tab. Nothing I changed should have had any impact on getting the client to work.

As to .NET framework, I would have to download a 250MB package (compressed) in order to run the GPU2 program. Only Microsoft would think that kind of bloat was a good thing. Once installed, there is a considerable amount of overhead running the program, might as well have used Visual Basic. Fast processors and large amounts of RAM subsidize efficient code. A project such as this begs for code efficiency. But I suppose that's how it is these days, no one writes in Assembly anymore. Small, tight, lean and mean -- there was skill. RIP

As to the typos in the line above: I suppose as long as the client is working, most people wouldn't noticed this in their logs.

** Update #1 **

I was very irritated that morning with the client, that I had to get away from it. Today (2 days later) I decided to try it again. I started the client and bingo, it downloaded. Since it went from not working to working without me doing anything, it's clearly beyond my control.

Now that the client is working, I've noticed more deficiencies with the Display Viewer. The Display Viewer doesn't do much, contrary to the FAQ. Coming from the PS3, I was expecting to see in the Display Viewer some stats. Such as how large of a WU, how much time it is expected to take and when it is expected to be completed. Some kind of progression indicator and identifier. Nothing but spinning balls.

Part of these expectations came from the various FAQs. Some of these FAQs are hopelessly out of date and need to be updated or removed. For example, it was the "WinGraphicInstall" FAQ off the download page that included a video by Michael Burk. In the video it shows that the installer allows the user to install FAH in a directory of their choosing. In addition, the user would be allowed to choose a location for the shortcuts. These options are no longer available for some unknown, and likely poor, reasoning.

There's a Screensaver? Where? The instructions say there's one, but the Screensaver tab in the Windows Display properties disagrees as well as the FAH Client configuration.

Download indicator? Where? The only sign that anything is happening is when you mouse-over the System Tray icon. Really! Is that the best anyone could do to indicate that something is happening?

Display tab? Why was that removed from the FAH configuration? Seems being able to control the Draw Rate would be a good idea. But then I beginning to realize that good ideas don't stick around long.

For whatever the reason for these changes and omissions, this is what a first time user is going to see when they consult the FAH information. I find it curious that if, as you suggest, the configuration can play a major role in breaking the client, shouldn't there be a configuration reset button someplace obvious?

** Update #2 **

Once the WU was completed, it was sent back and credited successfully. It then immediately attempted to download a new WU and that has continued to fail. As of this moment it was on attempt 21. That translates to 10 wasted hours. Arrrgh!

See what I mean: I take it that the log file will continue to balloon to a really huge size since there is no cutoff control on just how large it can become.

As I sit here I'm beginning to wonder just how many potential users FAH has lost to problems such as these. What is the acceptable casualty percentage?

I'm a first time Windows client user and at least I made my way to these forums for help, where I took the time to register. Which, BTW, that in and of itself was a bloody nightmare. Every time I attempted to post I would get some stupid reminder that the post was rejected because, and I'm paraphrasing, "You can't include a URL until you have made 0 legitimate posts for 0 days". Huh, what URL? You wouldn't know this, but even to this day I have never received a response from the powers that be about the account problem I submitted. Not one of three people, individually or collectively, could mustard up some human decency to let me know that the account was apparently fixed awhile back. I found out accidentally.

For those that have persevered through the forum registration process who are trying to contribute, there is hope as they post their heart felt concerns for help. And, out of the bleak mire, only from the courtesy of other users, does a response echo from these walls of perpetual silence.

Sorry for the rant, I am extremely frustrated. All I want to do is contribute to FAH. Instead, I'm feeding money to the power company while the FAH client randomly decides if it wants to work or not.

I'm sorry for your frustration. In fact, the Pande Group is not a software house but rather a relatively small group of biochemists/scientists with a pretty small budget for software development. As such, the science gets emphasized rather than issues that are more cosmetic in scope.

The viewer on the PS3 is the most advanced viewer available. (That was a priority for Sony, and it does make sense on a game console.) The CPU does not have the resources to provide such a sophisticated viewer, so even after the bugs are fixed, you'll probably be disappointed. Nevertheless the Pande Group intends to produce a worthwhile viewer for the PC but it's has not been a priority. The main emphasis has been on getting three new science platforms to produce reliable scientific results -- Two versions of the Windows GPU client and the Linux/OSX SMP platform plus a new version of the server code. The rewrite of the server code is currently being tested and I expect that when it's rolled out, that the connection problems that you're experiencing will go away.

As far as writing in Assembly is concerned, you'll probably be appreciative of the fact that the inner loops of the Gromacs code are hand-coded Assembly Language code with all the loop-unrolling and SSE instructions that it takes to get really high floating point performance out of a CPU. The rest of the code is compiler-generated, but it doesn't spend much time running that code so optimizing it isn't worth the time spent.

Tynat wrote:While I do most of the FAH work from my PS3, I'm considering using my PC for further processing overnight. The PC has a single 3.0 GHz P4 processor, 2 GB of RAM, a ATI HD-3850 (AGP) graphics card and running WinXP SP2.

As best as I have been able to determine I have two choices, the Windows XP client (System tray) or the GPU1 client. Can't/won't install the GPU2 client.

Based on the above PC hardware specs, which client should I install?

GPU1 client is no longer available, and won't work with your 3850 anyhow.

If you want efficient Folding, use the CPU Console client, and disregard the viewer and the screensaver. Set it to run as a Service, and let it do what it does. INCREASE the logging interval to the max 30 minutes, and use the -verbosity 9 switch if you want more information available. FahMon (viewtopic.php?f=14&t=40) will monitor progress.

The Stanford servers occasionally time out, but the relative impact is minimized with the CPU client.

Solution to the custom installation folder would be using the console client, which you could just extract anywhere you want. But I completely agree about the systray client's installer automatic scheme. Common answer to that is that it now follows microsoft's intended scheme, but many people (me included) dont care about where microsoft wants to install it.

Be sure to have the client configured to accept at least middle sized WUs or prefferably big WUs if you dont want to wait 10 hours for another assignment, as there probably isnt enough small sized WUs. Also do not request deadlineless WUs, as far as I know, there arent any.
By the way, dot net 2 installer is only about 20 MBs in size, not 200 MBs, and the GPU client is much more productive. And neither the CPU or ati GPU client should interfere with your work on the PC.

bruce wrote:The viewer on the PS3 is the most advanced viewer available. (That was a priority for Sony, and it does make sense on a game console.)

Clearly I must be missing something. Why is it that the viewer shown in the video by Michael Burk from the FAH WinGraphicInstall page shows an advanced viewer with all sorts of useful information being displayed? What happened to that viewer, the one us first time users are going to expect to see? And, that's not the only erroneous information the video provides.

bruce wrote:The CPU does not have the resources to provide such a sophisticated viewer, so even after the bugs are fixed, you'll probably be disappointed. Nevertheless the Pande Group intends to produce a worthwhile viewer for the PC but it's has not been a priority.

The CPU does have the resources to provide a sophisticated Display Viewer, just not three or more of them running all at the same time. The point being that other than the first instance of the Display Viewer, the user shouldn't be able to start additional instances. Selecting the Display Viewer a second time should only bring the first instance of the Display Viewer back into focus.

bruce wrote:plus a new version of the server code. The rewrite of the server code is currently being tested and I expect that when it's rolled out, that the connection problems that you're experiencing will go away.

I sincerely hope so, because while I am able to connect to the server (according to the log), I have only once been able to download a WU. Tonight, after a six day hiatus, I tried the Win Client again and the connection is still borked. Only that one time did it work from stem to stern.

Looking over the log file a little closer shows that the one time the client did work, the client couldn't find FahCore_78.exe. Apparently it had to download it into the Application Data directory. It is there now. Perhaps the installer isn't installing files in their correct locations and that is contributing to the problem?

bruce wrote:As far as writing in Assembly is concerned, you'll probably be appreciative of the fact that the inner loops of the Gromacs code are hand-coded Assembly Language code with all the loop-unrolling and SSE instructions that it takes to get really high floating point performance out of a CPU. The rest of the code is compiler-generated, but it doesn't spend much time running that code so optimizing it isn't worth the time spent.

Actually that does make be feel warm inside.

jrweiss wrote:GPU1 client is no longer available, and won't work with your 3850 anyhow.

That is unfortunate.

jrweiss wrote:If you want efficient Folding, use the CPU Console client, and disregard the viewer and the screensaver.

There's a screensaver?

jrweiss wrote:Set it to run as a Service, and let it do what it does. INCREASE the logging interval to the max 30 minutes, and use the -verbosity 9 switch if you want more information available. FahMon (viewtopic.php?f=14&t=40) will monitor progress.

What does setting the logging interval to 30 minutes achieve? Is that to minimize the impact on the hard drive at the lost of greater chunk of work should there be a failure of some kind?

I originally dismissed the Console client due to being unfamiliar with command switches, I'll reconsider the Console client. However, the Win client should work. Otherwise, if the Win client is problematic perhaps it should be temporarily pulled from the download page.

** Update **

I tried the console client and was immediately turned off by it's complete and utter lack of being able to store it's extra files where the EXE is located. Dumping these files into the root of the drive is a horrible practice. The console client has been deleted.

jrweiss wrote:The Stanford servers occasionally time out, but the relative impact is minimized with the CPU client.

On the PS3, I lost completed WUs. I certainly hope that doesn't continue to happen.

^w^ing wrote:Solution to the custom installation folder would be using the console client, which you could just extract anywhere you want.

** Update **

As I mentioned above, technically that's not the case. I tried the console client and was immediately turned off by it's complete and utter lack of being able to store it's extra files where the EXE is located. Dumping these files into the root of the drive is a horrible practice. The console client has been deleted.

^w^ing wrote:But I completely agree about the systray client's installer automatic scheme. Common answer to that is that it now follows microsoft's intended scheme, but many people (me included) dont care about where microsoft wants to install it.

Apparently, both the installation directory and shortcuts use to be configurable. The installer could just offer the default, but still allow the user to choose a location. What would happen if your Program Files directory is on a completely different drive? I also don't care for the way the installer buries the installed files in an empty Folding@home directory.

^w^ing wrote:Be sure to have the client configured to accept at least middle sized WUs or prefferably big WUs if you dont want to wait 10 hours for another assignment, as there probably isnt enough small sized WUs. Also do not request deadlineless WUs, as far as I know, there arent any.

I'm not following what you wrote. I only know about the WU for the PS3 and that's a fixed size of 300,000 and takes on average 7½ hours to complete.

^w^ing wrote:By the way, dot net 2 installer is only about 20 MBs in size, not 200 MBs,

The installer for the latest version of .NET is 250MB, but you bring up something I forgot about. Since these versions are not backward compatible, it would take at least 270MB just to get up to date.

And why .NET? Is that the only way to access the GPU?

^w^ing wrote:and the GPU client is much more productive. And neither the CPU or ati GPU client should interfere with your work on the PC.

I know what your saying. However, with the current install of the Win client not working, its not interfering at all.