Folding Forum

Yeah, make sense. I missed that section so I made assumptions instead

Hi

Always trying to optimise my system and found this tread. Not beeing to steady in tecnical english, im asking you. What would the Profile lines be for best perfomance of my 2 folding Pc's.

PC1: Windows XP 32, Intel Quad, running 1 SMP and 2 GPU's.
PC2: Windows Vista 32, Intel Quad, running 3 GPU and 1 SMP.

BrgHW, I am not completely sure which configuration would be optimal for your case, but I can tell you how to write the profiles if you tell me how you want to allocate the cores to processes.

I can list a few possible configurations you could try.
First, I assume you are running a Windows SMP client and not a Linux one inside VMWare.

For PC1: On XP, a GPU client uses a core at 100% because it is spin waiting while waiting for results from the GPU. But I've read on this forum that if you allocate 2-4 GPU clients to the same core, there is minimal slowdown even on XP. I cannot test this myself, but I am going to assume it is true.
So, I would allocate both GPU clients to the same core, let's say core 0, with the following rule. On your machine you must use the actual path to your GPU client instead of "C:\PathToGPUClient".

On XP it is not a good idea to mix GPU clients and CPU clients onto the same core. So, we'll use the other three cores for the SMP client. I think you have at least three different configurations that you could try. These are the same as the ones that I wrote for Anachron a few posts above. I am just going to copy/paste them. You will use the same GPU profile in all cases.

1) All remaining three cores are allocated to all four SMP processes: Again, you'll have to use the actual path to your SMP client on your machine.

2) Allocate one core to each process, except for the lightest two process that get allocated to the same core. 3) Allocate one core to each process, except for the lightest process which will have its affinity set to all three cores. Read a few posts above for the explanation.

For PC2: On Vista GPUs take little CPU time, so you can easily allocate all three GPU clients to the same core. You could also use that core for the SMP client when the core it's idle.
For this we need to use priority settings as well. The rule for the GPU clients becomes: Again, you must use the actual path to your GPU client on your machine.

For the SMP client, you could use either of the three variants I wrote for PC1.

4) In addition, you could try a fourth variant where each process gets allocated one core, except for the lightest process that can run on any of the four cores on your machine, including the core allocated to the GPU clients.
The profile line is going to be quite long in this case. In your configuration file the rule has to be on a single line.

If you do not want to try all of them, you could use the 3rd variant for the XP machine, and the 4th variant for the Vista machine. Make sure to use the priority attribute if you go with the fourth variant on Vista. The GPU clients should have a slightly higher priority than the SMP processes.

Hi.

Thank You for a fantastic good answer

Starting on PC1. And did put these 3 lines in :

G:\Programfiler\Folding@home\Folding@home-gpu\FahCore_*.exe := CPU0
G:\Programfiler\Folding@home\Folding@home-gpu 2\FahCore_*.exe := CPU0
G:\Programfiler\Folding@Home Windows SMP Client V1.01\FahCore_*.exe := CPU1+CPU1+CPU1+CPU2+CPU2+CPU2+CPU3+CPU3+CPU3+CPU1+CPU2+CPU3 [assign=3,resource=CPUUSE,policy=PSEUDOBALANCED]

Running in test mode and got this on screen:

G:\Mid\AffinityChanger-0.82>affinitychangerconsole
AffinityChanger 0.82, (c) 2008 <[email protected]>

Auto detecting CPU configuration. Please wait.
|==================================================| 100.0%
Found 4 CPUs:
CPU0 has mask 00000001
CPU1 has mask 00000002
CPU2 has mask 00000004
CPU3 has mask 00000008
Found 2 PAIRs:
PAIR0<CPU0,CPU2> has mask 00000005
PAIR1<CPU1,CPU3> has mask 0000000A
Warning ApplicationProfile::finalize: CPU mask for application profile "G:\Programfiler\Folding@Home Windows SMP Client V1.01\FahCore_*.exe" contains duplicate
CPUs. I hope you know what you are doing.
12.10.2008 18:06:23: G:\Programfiler\Folding@home\Folding@home-gpu 2\FahCore_11.exe with PID 1032, set affinity to CPU0
12.10.2008 18:06:23: G:\Programfiler\Folding@home\Folding@home-gpu\FahCore_11.exe with PID 7400, set affinity to CPU0
12.10.2008 18:06:23: G:\Programfiler\Folding@Home Windows SMP Client V1.01\FahCore_a1.exe with PID 8824 using 89.5% of CPU time, set affinity to CPU1+CPU1+CPU1
12.10.2008 18:06:23: G:\Programfiler\Folding@Home Windows SMP Client V1.01\FahCore_a1.exe with PID 4376 using 77.2% of CPU time, set affinity to CPU2+CPU2+CPU2
12.10.2008 18:06:23: G:\Programfiler\Folding@Home Windows SMP Client V1.01\FahCore_a1.exe with PID 4608 using 62.5% of CPU time, set affinity to CPU3+CPU3+CPU3
12.10.2008 18:06:23: G:\Programfiler\Folding@Home Windows SMP Client V1.01\FahCore_a1.exe with PID 3264 using 60.0% of CPU time, set affinity to CPU1+CPU2+CPU3

There is a warning, and i'm not shure of what i'm doing
Have I done somting wrong or is it OK??

BrgHW wrote: There is a warning, and i'm not shure of what i'm doing
Have I done somting wrong or is it OK??

Yes, that is fine. I print that warning in case somebody inadvertently lists the same CPU multiple times for one application profile. It is legal however to list the same CPU multiple times in case one needs to write profiles where processes get allocated different numbers of CPUs, as in your case.
If you do not want to see that warning, set the WarningLevel to 1 in your configuration file. But I would say just leave it alone and ignore the warning because you know what you are doing.

BTW, you can also combine your GPU profiles into a single one if you use a wildcard ('*') in the name of the path. This could be useful if you have a large number of GPU clients that get assigned to the same core and you do not want to write a separate rule for each one.

Ok, Thank You again.

Starting it up now. Will post if there is any change in total ppd for this PC.

EDIT : Starting up PC2 with the 4th variant also.

Results after 2h run.
PC1, no change in PPD.
PC2, on CPU ppd lost 300 and on GPU1 lost 100p. Total ppd lost 400 points.

Shutting down for now.

Hi BrgHW,

I sure am glad I mentioned before hand that I do not know which configuration would give most points with your setup.
I only provide a tool that enables users to test different configurations and to automate the setting of affinities once a configuration is defined.

But I have a side interest in understanding the optimal assignment of processes to cores for a given setup.
Can you post your previous settings for the Vista machine? Were you setting any affinities for the GPU clients? How about the SMP processes?
Is this machine a dedicated folder, or do you use it for other light work as well?

I think it is better for me not to suggest another configuration before you post your current settings.
I would not expect big gains from setting affinities with your setup, but I would think no affinity settings is not the optimal setup either.

Cheers,
baobab

Hi again.

Yes the Vista machine is atm. dedicated to folding only and I had no special settings for this machine before.

And it's ok that it didn't work at first try. Rome was not built in one day. You are doing a superb job.

I thinking that maby Vista is making the best balansing of work it self. Not shure of that of course, but It's a possibility. I'm sorry I did'n think of looking at CPU usage during the test.

In XP there is somting to gain I think, and I wil try again. But I will wait until I'm finnished a miner relocating of the GPU's. Waiting for a new GX2 card + bigger PSU for PC1, and the cards will switch machine. So I will have 2xGX2 in one PC and 1x8800GTS + 2x8800GS in the Vista PC.

On the XP machine you are somewhat limited in what you can do with affinities because you have to keep the GPU clients and the SMP clients separate. On Vista you have more flexibility, and there are many possible configurations to try.

When you are ready to give it another try, I am thinking of going in a different direction than on your first attempt for the Vista machine.

The a1 FahCore of the SMP client is obviously imbalanced. One process does more work than the other three, so I think the critical path for this client is represented by the most expensive process. I think that maximizing the output from the SMP client requires having the most expensive process set to a single core alone, so its cache locality is best.

I am thinking that you should try to assign a different core to each GPU client. This accounts for three cores. Then assign the fourth core to the most expensive SMP process. The other three processes of the SMP client can float freely on the three GPU cores.
The profiles would look something like: If you are adventurous, you could try also sticking each SMP process to one core. The most expensive SMP process should be alone onto one core. The other three processes share a core with one GPU client. Because your GPUs are heterogeneous, and you know which GPU client corresponds to each GFX card, the more expensive SMP processes should share a core with the GPU clients running on the slower cards (they should use the CPU less).

You can either assign the cores to the GPU clients starting from the most expensive GPU client assigned to CPU0 to the least expensive client to CPU2, or write a rule that balances the GPU clients dynamically like this: The most expensive GPU client would share a core with the least expensive SMP client, and so on. The most expensive SMP process share the core with nobody.

Again, these are just some idea thrown out there. It is difficult to predict which configuration is better.

Of course you could increase your output by running two Linux SMP clients inside two VMWare machines, each assigned to one PAIR of cores, and the GPU clients assigned one per core. But perhaps you do not want to deal with Linux and virtual machines if you did not go in this direction.

Thanks, baobab. That was a long and very helpful answer.

And that last profile you gave does exactly what I was looking for, although I don't know if it actually is the most optimal one. I'll test the other profiles too, later I guess...

-Anachron

baobab, you've made very kindfull tool! I use it with a great pleasure, but is it possible to add the ability this program to be set up as a service. Something like start switches "-register" and "-unregister". I gues it is not so hard for you, but very usefull if I don't want to see the console window in the task bar all the time.

Aleksey, over the past week I've been working on a sys-tray version of the program. It is not a service, but it can be hidden from the taskbar.
The tray version is not quite finished yet, but it is not far off either. I want to release it roughly a week from now.

I am looking for somebody to test it in Vista sometime next week before I release it though.

In the mean time one could use an application like TrayIt, for one example.

baobab wrote:Aleksey, over the past week I've been working on a sys-tray version of the program. It is not a service, but it can be hidden from the taskbar.
The tray version is not quite finished yet, but it is not far off either. I want to release it roughly a week from now.

I am looking for somebody to test it in Vista sometime next week before I release it though.

I'm afraid, I do not have any Vista PC around. My company is on XP totally. My home PC runs XP also. The reason to require "service" version is to hide it at all also. I've got non-SMP clients running as services and users even don't know about it. If it is 2 Core PC and I run 2 such the clients simultaneously, your tool is usefull already. And even if I want to keep one of cores only for folding then I can use it. But I don't need the headache to explain to all these people what the new hell is sitting in the tray. Here are my reasons and I'm definitely ready to beta test it

Concerning the tray version, I can test it on my home PC (XP Home SP3) and on 2-3 of my work servers (W2K3 Standart) anyway. But keep in mind that I'm on vacation 2 weeks from 27th of October, so this time is not for testing.

My reason for having a systray icon is that you can interact with the application through a context menu. For example you can open/hide a console to see any log or error messages, you can load a new profile without restarting the application, you can pause it, or restore affinities and priorities to their original value.

I can easily add an option to hide the icon though. To get it back just try to execute the application again. It will not start another instance, but it will show the icon of the old instance. At least this is the plan I've not implemented this last part, but I think it is not that difficult to add.

I will let you know when I have the beta ready (before you leave on vacation most likely ).
I have a Win XP machine at home, that's why I was interested especially in somebody with Vista to test it. But I appreciate even some XP testing. Environments differ from one machine to another.

I am not opposed to having it optionally installed as a service, but I need to research the topic first, so that will be maybe in the following version.