Folding Forum

wouldn't it be easier to maintain only uniprocessor core, and to avoid installing a seperate client per gpu/cpu/core, do:


(please distinguish "client" from "core")


1. client starts up. (i.e. Folding@Home-Win32-x86.exe)
2. client takes number of processor/core with -smp flag (maybe even -gpu treated the same way!)
3. client spawns thread for each processor/core
4. client sets processor affinity for each thread.
4. each thread spawns a uniprocessor core or gpu core (and create a subdirectory for each core.)



this way I see it, is that if programmed this way, the client becomes a universal client (as often requested), with less source code for science to maintain. This is all while making full use of your hardware's available resources without a radical redesign of the current system. it is not be complicated to install/deploy/configure client with this change either.

I can see the benefits of having this - or perhaps having it as an end goal, but i expect it really is fraught with problems. Indeed, I suspect you haven't properly worded you first sentence to convey what I suspect you're trying to put out there?

One of the advantages of not having a all-in-one client is that using separate clients is 'modular' ie, if you don't GPU fold, you can avoid having to use that module. Furthermore, The issue with the above is each time the GPU component of the universal client is updated, then all users would need to update their client.

Throw in the fact that 'universality' requires compensating for all the different architectures etc, and it's a big mountain to climb. After all, not all environments are the same, and making sure that the 'universal' client works on. Even stuff as simple as having/not having a password-enabled accounts would probably be enough to make the whole thing fall over.

Simply put, you cannot only maintain a uniprocessor core because and the CPU core just simply won't work in the GPU environment.

In essence, I suspect what you're advocating is the dropping of SMP for a multi-uniprocessor client?

Or alternatively, you're trying to advocate an 'umbrella' client?

k1wi wrote:
In essence, I suspect what you're advocating is the dropping of SMP for a multi-uniprocessor client?

that is correct.

As you noted, a universal client has been a perpetual request.

But as often occurs, Folding@home is breaking new ground on new architectures. That means fresh raw software, not well suited for universal compatibility. Until last month, the Windows SMP client was a kluge of 3rd party software, just to make it run. And several years later, still remains in a beta status. But with the a3 core, MPICH will go away, making the install much easier, and the client much more reliable.

But the project has made progress in this regards previously. The Linux fah client is CPU and SMP universal, using the same .exe for both types.

But your # 5 does not help the project as much as a true SMP client. Spawning multiple copies of a CPU client means that each spawn works on a separate work unit much more slowly. Multiple cores working on a single WU could fold a larger work unit must faster, helping the project more. Why would you suggest going backwards?

Anyway, I imagine there are big changes coming now that fah has hired a professional programing company to help with software development.

There are some disadvantages that should also be considered.

Let's talk about the SMP client which already is a semi-universal client. It can run either as a uniprocessor client or as a SMP client.

People who download it believe that they're downloading a SMP client which will run projects using multiple CPUs. There have been a lot of cases where folks complain that after installing the client, it only uses one core. It turns out that many people manage to start it as a uniprocessor client so that it receives an assignment which is ideal for uniprocessor machines. (This happens simply because at some point during the installation, they start the client with an incorrect setting.) Then we have to walk them through the steps required to finish the uniprocessor assignment that they've received and then switch to a SMP assignment for their next assignment.

One possible way to prevent this from happening would be to take away the configuration choices that allow it to be customized "wrong". That's not a good idea, though. There are a number of good reasons why those choices should remain configurable by the donor, to say nothing about the fact that it would make a lot of people unhappy if the client made all the choices for you.

For example, there are cases where you might want to run several uniprocessor assignments on SMP hardware (e.g.- where it's only running a few hours per week and the SMP deadlines are too tight) or maybe you need to run at less than the maximum resources (such as 3 uniprocessor assignments or 3 SMP threads on a Quad machine) because it slows down perceptibly when running either the full complement of threads or the full complement of simultaneous WUs.

bruce wrote:There are some disadvantages that should also be considered.

Let's talk about the SMP client which already is a semi-universal client. It can run either as a uniprocessor client or as a SMP client.

People who download it believe that they're downloading a SMP client which will run projects using multiple CPUs. There have been a lot of cases where folks complain that after installing the client, it only uses one core. It turns out that many people manage to start it as a uniprocessor client so that it receives an assignment which is ideal for uniprocessor machines. (This happens simply because at some point during the installation, they start the client with an incorrect setting.) Then we have to walk them through the steps required to finish the uniprocessor assignment that they've received and then switch to a SMP assignment for their next assignment.

One possible way to prevent this from happening would be to take away the configuration choices that allow it to be customized "wrong". That's not a good idea, though. There are a number of good reasons why those choices should remain configurable by the donor, to say nothing about the fact that it would make a lot of people unhappy if the client made all the choices for you.

For example, there are cases where you might want to run several uniprocessor assignments on SMP hardware (e.g.- where it's only running a few hours per week and the SMP deadlines are too tight) or maybe you need to run at less than the maximum resources (such as 3 uniprocessor assignments or 3 SMP threads on a Quad machine) because it slows down perceptibly when running either the full complement of threads or the full complement of simultaneous WUs.

Bruce what are you talking about when you say “This happens simply because at some point during the installation, they start the client with an incorrect setting.” When I installed the clients I was not offered any settings. You follow that statement with “Then we have to walk them through the steps required to finish the uniprocessor assignment that they've received and then switch to a SMP assignment for their next assignment” What steps are you talking about? The client I downloaded and installed was the SMP for AMD processors. F@H uses core four at about 75%, almost 30% for cores two and three and does not even touch core one, ever. Are you saying there is a way to change that?

Are you saying that there is help for the average user to be found someplace around here? If so you are sadly mistaken. F@H is a tweaker’s club, to gain the knowledge needed to properly configure, using command line parameters, is a lot more effort than most volunteers would or should have to do.

I agree with the OP on a few points but his terminology needs some work. What we really need is a shell to configure, launch and maintain each individual client. The shell itself is all the volunteer should see and have the ability to adapt on the fly to changes in the volunteers work load and system configuration. For example; if the customer installs a new GPU it should automatically detect the new GPU and ask that volunteer if they would like to apply F@H to that GPU. The shell application would handle the complexities of selecting, installing and configuring the new client on the volunteer’s computer system.

kzaske wrote:Bruce what are you talking about when you say “This happens simply because at some point during the installation, they start the client with an incorrect setting.” When I installed the clients I was not offered any settings. You follow that statement with “Then we have to walk them through the steps required to finish the uniprocessor assignment that they've received and then switch to a SMP assignment for their next assignment” What steps are you talking about? The client I downloaded and installed was the SMP for AMD processors. F@H uses core four at about 75%, almost 30% for cores two and three and does not even touch core one, ever. Are you saying there is a way to change that?

At at time when no WU has yet been downloaded, if you start the SMP client WITHOUT the -smp or the -smp N flag it will download a WU from a classic/uniprocessor project which will only use one CPU-core. I've never spent enough time installing the SMP client to figure out which step some people miss so that that happens but we've tried to make the installation procedure very, very explicit to avoid this trap and people still do it. Once a unprocessor (classic) assignment has been downloaded, it will only use one CPU-core (e.g.- FahCore_78 or FahCore_a0 or ....).

You didn't specify which OS you're running or which FahCore is being used by those projects. There are currently three FahCore's which do run SMP: FahCore_a1, FahCore_a2, and FahCore_a3. FahCore_a1 has never done an effective job of using 100% of your processor resources, but it was the first SMP core, and it was a huge improvement over the uniprocessor cores. It always runs four tasks.

Later, FahCore_a2 was developed. It got better utilization, but there were some serious difficulties getting it ported to Windows, so it remains restricted to Linux/MacOS. It could be configured for four or more tasks. Both FahCores_a1 and _A2 use MPI which allows multiple tasks to work together on a single job. MPI works, but it also has probably contributed to some of the known problems that we've seen with these FahCore's.

FahCore_a3 has been getting a lot of attention recently. It seems to solve many of the problems we've seen with _a1 and _a2. It still has some bugs, but possibly fewer than remain unfixed on _a1 and _a2. Also, as they are reported, they're getting fixed. It does not use MPI but rather uses multi-threading so a single task can utilize multiple CPU-cores. It works quite effectively with two or more CPU cores. Presumably it will soon be stable enough to stop calling it a beta core. Once that happens, I expect that projects using cores A1 and A2 will be migrated or ended.

Okay so I assume that the SMP advantage is sharing memory accross threads; I can't think of any better reason. But regardless of why SMP is faster, my suggestion can still stand. The client can still be launching a SMP core *and* GPU core(s) from within the same client.

kzaske wrote:Bruce what are you talking about when you say “This happens simply because at some point during the installation, they start the client with an incorrect setting.” When I installed the clients I was not offered any settings. You follow that statement with “Then we have to walk them through the steps required to finish the uniprocessor assignment that they've received and then switch to a SMP assignment for their next assignment” What steps are you talking about? The client I downloaded and installed was the SMP for AMD processors. F@H uses core four at about 75%, almost 30% for cores two and three and does not even touch core one, ever. Are you saying there is a way to change that?

Assuming you're running the client from a Windows shortcut:

1) Shutdown your current work unit.
2) Edit the Shortcut properties and add "-oneunit" to the end of command line (without Quotes)
3) Relaunch the client. It'll automatically shutdown after completing and transmitting that unit.
4) Edit the shortcut again, replace "-oneunit" with "-smp"
5) Relaunch the client, it'll now be running in SMP mode, fully utilizing all cores.

bruce wrote:At at time when no WU has yet been downloaded, if you start the SMP client WITHOUT the -smp or the -smp N flag it will download a WU from a classic/uniprocessor project which will only use one CPU-core. I've never spent enough time installing the SMP client to figure out which step some people miss so that that happens but we've tried to make the installation procedure very, very explicit to avoid this trap and people still do it. Once a unprocessor (classic) assignment has been downloaded, it will only use one CPU-core (e.g.- FahCore_78 or FahCore_a0 or ....).

I think what happens is that people don't open it with the indicated flags in the command prompt, as the guide instructs, but rather open the .exe directly or make a shortcut on the desktop and open that. Though it goes through the configuration, it's effectively only being run with the -config flag, so adding the -smp flag in the Additional Parameters field doesn't take effect since the client doesn't restart after config. I know I did that the first few times I installed it.

The eventuality I see is that SMP+GPU becomes the universal client, with uniprocessor going the way of single-core CPU's. The server would issue you a properly sized WU for your CPU power and available RAM, and a properly sized WU for your GPU's power. Ideally, it could also try to match the best WU for your CPU's SSE support, cache sizes, and architecture(Core2, K10, i7).

The current project that's working in this direction (I think) is the new GPU client and OpenCL support, that could eventually allow ATI and Nvidia to use the same client.

A problem I see with a universal client that optimizes for you is that some folders will not want 'optimization' for various reasons.
How will the server recognize other factors like environmental heat issues, internet connectivity, other uses you may have planned or such local issues as poweroutages? There would need to be a considerable user interface built in to allow the user to reconfig the client for local conditions.
For example my i7 920 is setup up and capable of doing big adv, and I have done a few of them, but I have frequent power and internet connection issues that make the adv methods A3 a better choice for me personally. Likewise I prefer running at -smp 7 rather than -smp 8 because I also have 2 gpus on this system.
How would the server recognise that a system was fine heat wise running 3 x uniprocessors but 4, or an smp would push it over the edge, despite having the resources available? The end result would be a scaling back of optimizations to the lowest common denominator.
I do support the idea of more easily installed clients as long as they maintain a high level of user configurability not just at setup. I know that the complexity of some of the advanced setups puts people off, and I have struggled with this myself frequently, but it does reduce the risk of people setting up things that they just can't run, or worse the project loading a configuration that the donor doesn't want.

You also forgot non-24/7 folders... My laptop only folds while its on. It certainly is on long enough to do unicores, but an smp would fail, though its quite capible of doing smp.

We are moving to eventually have a universal client. Our v7 client will be our first step, but it will take a while to get all the way there. Our goal is to make it easy for people to donate computer time, but there are several new developments which have to be done to get there.

VijayPande wrote:We are moving to eventually have a universal client. Our v7 client will be our first step, but it will take a while to get all the way there. Our goal is to make it easy for people to donate computer time, but there are several new developments which have to be done to get there.

WoHoo!!! Looking forward to seeing it. Any idea when we will get to play with it?