Folding Forum

While I agree with Bruce's general message, I'm thinking now that it is the user's choice and responsibility to use it or not, so I will most likely add it. Perhaps with a flag that must be checked first in the settings dialog box.
Adding the realtime setting is not going to take long. But I am traveling right now, so it will be after the New Year (Jan 3rd maybe).

baobab wrote:While I agree with Bruce's general message, I'm thinking now that it is the user's choice and responsibility to use it or not, so I will most likely add it. Perhaps with a flag that must be checked first in the settings dialog box.
Adding the realtime setting is not going to take long. But I am traveling right now, so it will be after the New Year (Jan 3rd maybe).

Can Affinity Changer confirm that the realtime request is for a client inside VMware and issue a strong warning if it isn't?

I do not check for any particular program name. The user specifies the name of the process for which to set affinity/priority.

But I assume you mean to check if the request is for a vmware-vmx.exe process? I do not see the processes running inside the VM machine, only the actual VM process. I could do that, but then there are many other programs that might need to be checked and I do not want to go there.

I will most likely just have a flag that the user must explicitly check to enable the use of realtime priority. Even if somebody sets some CPU intensive process to realtime priority, a reboot (optionally in Safe mode if things are auto-started) could easily fix a bad configuration.

The realtime is needed for the GPU(XP), not VMware(guest Linux). VMware runs Linux with SMP client at idle priority just fine almost without a hitch during gaming,browsing,etc. It's the GPU systray client/driver that gives me headache when it makes my computer stutter and freeze anytime(0xEA if you are familiar). The main reason I run VMware at all is stability- the windows SMP client looses WUs left and right when the GPU freezes, which it does whenever it feels like. This was the reason to install GPU console as a service. It worked great, but whenever VMware is running, the GPU client doesn't run at full speed because (IMO) windows considers it background task and VMware is running as a program. My PC works much better even with the realtime priority , and Priority Lasso already keeps it for me, but I like WinAFC much better and feel this option should be included.
If anything, doubt my shaders' speed, not VMware.

Props to Baobab! WinAFC is an amazing tool.

I recently came across WinAFC after fumbling around trying to find optimum settings on a newly upgraded box: Q6600 w/2 8800GS (swapped out P4 for quad) now running 2x Notfred VM appliances in addition to GPUs (vista 32bit). I concur with ExtraSalty, that it is necessary to run fahcore11 processes at realtime priority to get full GPU performance, while running the 2 VMs at low priority to grab remaining CPU cycles.

I echo the sentiment that realtime priority would be a very desirable and useful option. Lets not stifle Baobab's (& others') continuing innovation just because it can be anticipated (and reasonably so) that some folks will have configuration problems...

As pointed out earlier in this thread, VMware isn't officially supported so a person needs to know what to do if you have trouble. Further, anyone that has problems through the improper use of a WinAFC realtime priority setting feature has already decided to jump off into the deep end of the pool anyways, and should know how to resolve it or at least know where to go ask for help if necessary.

My 2 cents.

Just a note to let you know that I uploaded version 0.9.2 which adds support for realtime priorities. The user must first tick a checkbox in the general settings dialog box to enable their use. After that, just specify "priority=realtime" as part of an application profile.
Until today I did not work on the code, so there are only a few more minor code changes. If you do not need realtime priorities, you do not really have to update to the new version.

The program can be downloaded from the same place: https://sourceforge.net/project/platfor ... _id=238550
Documentation: http://affinitychanger.sourceforge.net/

And a Happy New Year to everyone.
baobab

It's so great to see a developer care and update his code as much as you do, baobab. Let us know if you have other projects- they are sure to be gems. Keep it up and good luck with everything!

I've encountered a little problem recently. I installed 64-bit Windows 7 and the 64-bit WinAFC, but the GPU client is 32-bit and WinAFC doesn't seem to touch it. The 32-bit WinAFC is exactly the opposite- it works only with 32-bit processes. Any solution?

The 32-bit version is not supposed to handle 64-bit processes, but the 64-bit one should be able to handle 32-bit processes. Now, I did not try anything under Windows 7, so maybe you can run a few tests.

Just to make sure, are you running the GPU client under the same user name as WinAFC, or under a different user name? If it is under a different user name you need to run WinAFC as Administrator.

If that is not it, can you create a minimal configuration file, let's say with rules just for notepad.exe (it should be 64 bit) and the GPU client (a 32-bit app), plus the following two lines, and let me know what WinAFC64 prints. Make sure you have Notepad open and the GPU client running when you start WinAFC64.

Next, can you change the rule for the GPU client to not include any path information, so just have a star followed by the process name with no backslash, like so: and let me know if that works.

Just as a feedback : I'm running WinAFC under Windows 7 and it doesn't have any problem managing affinities after I set WinAFC to run as Administrator. I guess the problem stem from the fact that if it isn't run as a Administrator, it doesn't see the system processes so it doesn't manage them at all.

I was too quick to complain- my configuration file changed and I just noticed it. The 64-bit version works just fine with 32-bit processes, even without run as administrator. I promise to do more research next time before I ask a question

Great, then I do not have to do anything.
Xilikon, you have to run it as Administrator to control processes running under the same user account? If you want to control system processes or programs running under a different account, then it is normal to require Administrator privileges.

I had to run as admin since VMWare processes are SYSTEM processes, not visible to the current account.