Configurable affinity changer for Windows

[p2501]

Wow, you're fast to reply! Thank you!

Just downloaded that new 64bit executable, the problem that you described was exactly what I was thinking, which is why I tried the not-working 64bit one first, hehe. Well, I'll try this now and report back!

Edit: You're right on spot with that correction:

Code: Select all

Auto detecting CPU configuration. Please wait.
14.11.2008 21:04:41: Found 4 CPUs:
	 CPU0 has mask 0000000000000001
	 CPU1 has mask 0000000000000002
	 CPU2 has mask 0000000000000004
	 CPU3 has mask 0000000000000008
14.11.2008 21:04:41: Found 2 PAIRs:
	 PAIR0<CPU0,CPU1> has mask 0000000000000003
	 PAIR1<CPU2,CPU3> has mask 000000000000000C
14.11.2008 21:04:41: C:\Users\root\FAH-GPU2\FahCore_11.exe with PID 3512, set affinity to CPU3
14.11.2008 21:04:41: C:\Users\root\FAH-GPU2\FahCore_11.exe with PID 3512, set priority to High.
14.11.2008 21:04:41: C:\Users\root\FAH-GPU\FahCore_11.exe with PID 3480, set affinity to CPU1
14.11.2008 21:04:41: C:\Users\root\FAH-GPU\FahCore_11.exe with PID 3480, set priority to High.
14.11.2008 21:05:29: C:\Users\root\FAH-GPU2\FahCore_11.exe with PID 3512, set affinity to CPU3
14.11.2008 21:05:29: C:\Users\root\FAH-GPU2\FahCore_11.exe with PID 3512, set priority to High.
14.11.2008 21:05:29: C:\Users\root\FAH-GPU\FahCore_11.exe with PID 3480, set affinity to CPU1
14.11.2008 21:05:29: C:\Users\root\FAH-GPU\FahCore_11.exe with PID 3480, set priority to High.
14.11.2008 21:05:29: C:\Program Files (x86)\VMware\VMware Player\x64\vmware-vmx.exe with PID 2812, set affinity to CPU0+CPU1
14.11.2008 21:05:29: C:\Program Files (x86)\VMware\VMware Player\x64\vmware-vmx.exe with PID 2812, set priority to Idle.
14.11.2008 21:05:29: C:\Program Files (x86)\VMware\VMware Player\x64\vmware-vmx.exe with PID 2312, set affinity to CPU2+CPU3
14.11.2008 21:05:29: C:\Program Files (x86)\VMware\VMware Player\x64\vmware-vmx.exe with PID 2312, set priority to Idle.

It works!
Thanks alot! Care to explain what the problem was?

[baobab]

I used a linker flag that said to merge the .text and .data sections. This was shaving a few KB off the executable. But it had the effect that there was no .text section and the code was in the .data section (the merged section had to be writable because it contained data).
But some Windows versions/installs (I could not figure out a pattern from only 2 reports - though both are Vista64) report an error if code is executed from the data section. This is a good thing because it eliminates some security threats. In hindsight, it was a bad trade-off to use that compile option for a few KB.

I reply fast because I am watching the thread and I get an email if a reply is posted. If I know the answer I reply when I see the mail.

[p2501]

Thank you for helping the Vista64 crowd out with this fix. Now on for a little tuning, if there's any left.. ^_^;

Can I set a process to Realtime or is this not implemented? (I wanted to see if this changes anything with 2xGPUv2 + 2xVM)

[baobab]

It can be implemented, it is no different than the other priorities. My philosophy is not to double guess the user (or do it as little as possible), but I did not include the realtime option intentionally because it can lead to unresponsive systems.
Especially with the folding clients I think that is a bad idea.

If you have the VMWare processes set to idle, I think the GPUs should be set at "belownormal". My prediction is that anything higher would not yield any measurable gains if this is a dedicated folding machine (no other expensive processes running). If it is not a dedicated folding machine then setting the priorities higher than the regular Windows processes that handle the GUI, will just result in a sluggish system.

[Mr.Nosmo]

First, I'll like to thank "baobab" for all the good work - THANKS!

I guess I'm the first Dual Xeon 54xx (Quad Dual?) and want to keep you posted on how it goes for me - Worked first time after getting the new 64bit executable!

My system is:
TYAN 5392 Motherboard
Dual Xeon 5430 (2666MHz/2x6MB Cache)
4x2GB FB-DIMM (667/800MHz)
Dual FireMV 2200 Graphics
Adaptec 5805 8-port SAS RAID-Controller
1x 75GB Seagate Savvio 15K (SystemDisk)
7x 1TB WesternDigital RE2-GP in Raid-5 (File)
2x 300GB WesternDigital VelociRaptor (Data)
Windows Vista x64

I just started to run 4x SMP-clients, got 4x 2653 projects (the nice & fast 1760 points) and running the with AffinityChanger (please see config-file below), I get 1228+1337+1047+1481 = 5095 PPD - Can I change something to optimize the output?

TestMode = 0
WarningLevel = 2
ConsoleLogLevel = 4
FileLogLevel = 3
LogLevel = 3
TimeInterval = 30

C:\Folding@Home\SMP Client 1\FahCore_*.exe := PAIR0 [assign=1,policy=PSEUDOBALANCED,resource=CPUUSE,treads=NO,priority=IDLE,force=YES]
C:\Folding@Home\SMP Client 2\FahCore_*.exe := PAIR1 [assign=1,policy=PSEUDOBALANCED,resource=CPUUSE,treads=NO,priority=IDLE,force=YES]
C:\Folding@Home\SMP Client 3\FahCore_*.exe := PAIR2 [assign=1,policy=PSEUDOBALANCED,resource=CPUUSE,treads=NO,priority=IDLE,force=YES]
C:\Folding@Home\SMP Client 4\FahCore_*.exe := PAIR3 [assign=1,policy=PSEUDOBALANCED,resource=CPUUSE,treads=NO,priority=IDLE,force=YES]

[Mr.Nosmo]

HURRA for AffinityChanger!!!! - Now I'm up to 1563+1642+1225+1762 = 6192 PPD!

[baobab]

Hi Nosmo,

So it detects the 4 PAIRs for you. Great and thanks for the report.

TestMode = 0
WarningLevel = 2
ConsoleLogLevel = 4
FileLogLevel = 3
LogLevel = 3
TimeInterval = 30

First, just a small correction. LogLevel is just a shorter way of changing the verbosity of both console and file logging.
So if you set ConsoleLogLevel or/and FileLogLevel first, and then you set LogLevel to a different value, LogLevel will change both flags to the new value. This is very minor. Just to let you know what the flags mean.

C:\Folding@Home\SMP Client 1\FahCore_*.exe := PAIR0 [assign=1,policy=PSEUDOBALANCED,resource=CPUUSE,treads=NO,priority=IDLE,force=YES]
C:\Folding@Home\SMP Client 2\FahCore_*.exe := PAIR1 [assign=1,policy=PSEUDOBALANCED,resource=CPUUSE,treads=NO,priority=IDLE,force=YES]
C:\Folding@Home\SMP Client 3\FahCore_*.exe := PAIR2 [assign=1,policy=PSEUDOBALANCED,resource=CPUUSE,treads=NO,priority=IDLE,force=YES]
C:\Folding@Home\SMP Client 4\FahCore_*.exe := PAIR3 [assign=1,policy=PSEUDOBALANCED,resource=CPUUSE,treads=NO,priority=IDLE,force=YES]

You got the rules right. These rules assign the most expensive and the least expensive process of each SMP client onto the same core of a PAIR, and the two middle processes onto the second core of the PAIR.

If you want to do a bit more experimenting, I would try also some load balancing between the processes. That is to have the least expensive SMP process float on both cores of the PAIR because I think the most expensive + the least expensive processes use more CPU time overall than the two middle processes.

So, for SMP1, the rule would be:

Code: Select all

C:\Folding@Home\SMP Client 1\FahCore_*.exe := PAIR0::CPU0+PAIR0+PAIR0::CPU1+PAIR0::CPU1+PAIR0::CPU1+PAIR0 [assign=2,policy=PSEUDOBALANCED,resource=CPUUSE,treads=NO,priority=IDLE,force=YES]

If you are trying to understand what is going on with that CPU mask, just note that PAIR0 without any resolution operator ('::') expands to PAIR0::CPU0+PAIR0::CPU1. So in total you have 8 CPUs listed in the CPU mask, and the rule assigns two CPUs to each process.

You can do the same for the other SMPs, just use PAIR1 instead of PAIR0 everywhere for the SMP2 client, and so on.

It is not guaranteed that these rules will do better than the simple rules you use now, but they just might.

[Mr.Nosmo]

I won't have time to play around with it before next weekend, but I must say this AffinityChanger is really good!!!

"Old" System (No OC):
Dual Xeon 5430 w/8GB
Dual ATI 3870
When 100% folding 2653's & 4743's (no other use) I get 3x ~1100/1600 PPD (3x SMP) + 2x ~2200 PPD (2x GPU) = 7700/9200 PPD
(Affinity not set/set, using TaskManager, to use 2 cores/SMP & 1 core/GPU and the *&%¤#! to set affinity after every WU).

"New" System (No OC):
Dual Xeon 5430 w/8GB
Dual FireMV 2200
When 100% folding (no other use) I get 4x ~1750 PPD (4x SMP) = 7000 PPD
(Affinity set using AffinityChanger to use 2 cores/SMP and it runs without "babysitting").

This is a gain of 150-650 PPD/SMP = 10-59% !!! WOW!

[baobab]

Just a note to let you know that I released version 0.9.1 of WinAFC. This version fixes the two severe bugs reported in the last few days and adds a "Settings" dialog box to adjust default options and other parameters from within a GUI.

Download link: https://sourceforge.net/project/platfor ... _id=238550
Manual: http://affinitychanger.sourceforge.net/
For users of the previous version the only new section is http://affinitychanger.sourceforge.net/#settings

ChangeLog:

2008-11-17 Version 0.9.1
Bug fixes:
- removed compile setting that was preventing the program
to execute on some systems;
- fixed bug that was causing the icon not to be restored in
the systray after an explorer crash;

New features:
- added a dialog box for changing program settings at
run-time and for specifying default startup options;

Changes:
- moved the restore affinity settings from the context menu
to the new general settings dialog box;
- when in test mode, the program prints a note at the end
of each affinity changing log message to inform the user
that affinity was not actually modified.

Please report any bugs you find.

[extrasalty]

Under general settings/restore affinities there are 6 total check boxes, but only 3 selections. Other than that the new menu is awesome.

[baobab]

All controls on that tab have a checkbox on the right. Check that checkbox if you want to make the current value of the control the default. A default value will be restored next time you restart WinAFC. Otherwise, the value will take effect only during current session, but the default value is not changed. It is a bit confusing, I give you that. I wanted to offer a finer grain control to setting the default values, instead of having a button to set all of them at the same time. But I am not a GUI person and perhaps the design should be rethought in the future.

[Pascal94]

hi Baobab,

I changed several components of my computer, and now I have this configuration:

CPU: Intel Core 2 Quad 9550
Memory: Corsair XMS2 2x1024 PC6400
OS: Windows XP 32

I run 1 SMP client. Can you help me making my inputfile for this configuration ?

thanks a lot,


Edit: is it the good one:

E:\F@H-SMP\FahCore_*.exe := PAIR0::CPU1+PAIR1+PAIR0::CPU0 [assign=1,resource=MEMUSE,policy=PSEUDOBALANCED]

[baobab]

Edit: is it the good one:

E:\F@H-SMP\FahCore_*.exe := PAIR0::CPU1+PAIR1+PAIR0::CPU0 [assign=1,resource=MEMUSE,policy=PSEUDOBALANCED]

If you use only one SMP client, then yes, I think that would be optimal. You cannot do better than having one process per core. In addition, that rule balances the use of the L2 caches. The largest and the smallest processes share an L2 cache, and the two middle processes share the other L2 cache.

[extrasalty]

I know your position on realtime priority, but it turns out this is the only priority that works for GPU console as service and VMware(see viewtopic.php?f=52&t=7667). Is it possible to implement it (maybe put a developer's flag in the profile to allow the realtime use). I hate to use task manager when I already have my profiles for WinAFC.

[bruce]

I know your position on realtime priority, but it turns out this is the only priority that works for GPU console as service and VMware(see viewtopic.php?f=52&t=7667). Is it possible to implement it (maybe put a developer's flag in the profile to allow the realtime use). I hate to use task manager when I already have my profiles for WinAFC.

FAH is designed to work in Linux, Windows, and MacOS-X. As such, the developers see no particular need for VMware and it's not officially supported. People are welcome to run VMware if they want to, but if you do, you're pretty much on your own. Moreover, a realtime setting that somebody could accidentally set in native Windows could be a real disaster.

Recently there have been a couple of bug reports that are in the "cannot reproduce" category. It's possible that those problems only show up when running in a VM. I'm not sure how Stanford is going to deal with those issues if it turns out that they're somehow related just to VMware.

The GPU client that runs in Linux (via WINE), is a similar unofficial development effort. The people who did it have put a lot of work into it and it has given them a way to run their GPU in Linux, but the only support that you can get for that is from the user community. (I expect that Stanford will create a GPU client for native Linux someday, but maybe they'll decide to support the client in WINE.) Right now the Windows client and the Windows drivers are still in the midst of the development process so it's too early to port a client to other OSs.