Prioirty=idle doesn't work properly

Unless I place specifically priority=0 in my client.cfg file, FAH will hog the clock cycles if a higher priority program is placed into the background. Even in the foreground a higher priority program still shares more clock cycles with FAH than it should. I am using Windows Task Manager to monitor what resources are used. It seems that the default setting of priority=idle doesn't put FAH low enough. I have seen this effect in fah504 and fah502.

Put the priority on low, in task manager.

dfonda said:

Put the priority on low, in task manager.

Click to expand...

The priority is on low in task manager either with priority=idle or priority=0. However the former competes with foreground and background modules of higher priority...strange. Only priority=0 seems to work to put FAH at the lowest priority even when background modules run.

I have definitely noticed that on dual core system FAH is hogging resources making the computer slow and unresponsive to normal priority events and programs.

First you need to know that the client.cfg file is a UNIX file and has to be edited with a UNIX capable editor. Having figure that out I changed the priority around from 0 to 96 [idle] setting.

At zero priority both cores used 3/4 of the of the cpu time when the system was processing a video file giving it only 1/4 of the cpu time. When the FAHs were put on pause, the video file shot up to 3/4 of the CPU time. With one FAH at 96, so called idle, it took priority over even foreground events which is ridiculous.

Clearly on dual core machines FAH is not functioning properly and I have to turn off one process to make sure important functions get done quickly. This is unacceptable and needs to be fixed....who needs to know this? I can't tell people that FAH won't affect their machine and then keep hearing how it slows things down and they want it off so their computer will work properly again.

I wonder if its software specific?

orion456 said:

I have definitely noticed that on dual core system FAH is hogging resources making the computer slow and unresponsive to normal priority events and programs.

First you need to know that the client.cfg file is a UNIX file and has to be edited with a UNIX capable editor. Having figure that out I changed the priority around from 0 to 96 [idle] setting.

At zero priority both cores used 3/4 of the of the cpu time when the system was processing a video file giving it only 1/4 of the cpu time. When the FAHs were put on pause, the video file shot up to 3/4 of the CPU time. With one FAH at 96, so called idle, it took priority over even foreground events which is ridiculous.

Clearly on dual core machines FAH is not functioning properly and I have to turn off one process to make sure important functions get done quickly. This is unacceptable and needs to be fixed....who needs to know this? I can't tell people that FAH won't affect their machine and then keep hearing how it slows things down and they want it off so their computer will work properly again.

I wonder if its software specific?

Click to expand...

Here's the problem: Every time your cache needs to go back to get data from a memory address, it's like you had to walk from your living room to the refrigerator. Every time your cache needs to get data from the HD, it's like you needed to jump in the car and head to the corner convenience store.

And every time you leave the living room, FAH says "he's gone, time to fold!".

It's not exactly WRONG, it's just that FAH has no way of knowing that you're coming right back to finish more work, over and over, again.

If some work you're doing requires the full bandwidth of your memory, or quick and repeated access to slower devices, it's just best to give FAH a lower priority than idle. Have you tried something in the range of 20 to 50?

Some tasks, like some games, just don't play well with ANY other program that is also cpu intensive, like FAH. Even though FAH will give up it's cpu cycles in about 1/2 of a second, it can NOT give up it's memory while it's standing by, and it will get annoying and unproductive if you need to do something like video editing (which is very dependent on repeated accesses to slower devices). That means FAH is starting and stopping, over and over, quite quickly.

Have you voiced this concern to Stanford over at the FAH forum? They might be able to fine tune some program parameter to minimize this problem, in the next client version.

You can easily edit the client.cfg file in notepad or the linux editor, by remembering this:

Immediately after the last normal letter on every line, there is a Unix end of line char (which may or may not be visible, depending on your editor and font).

So carefully position the cursor on the line you want to edit, and don't disturb the char right after the last normal letter.

proxy=none<Unix End of Line Character Here>

Adak

In FAH, priority=0 is idle priority, as low as it can get. Priority=96 is low and will allow FAH to interfere with other Apps. All my installs I can currently see say priority=0 (I didn't have to add that statement. Just let the config program default to idle) in the client.cfg except the SMP rigs. I suspect if you configure the SMP client to low priority you will get a priority=96 statement in client.cfg. I've never seen the statement not work and don't see lack of the priority statement causing unexpected interference on my SMP rigs.

ChasR said:

I've never seen the statement not work and don't see lack of the priority statement causing unexpected interference on my SMP rigs.

Click to expand...

Here is prime95 running as a foreground object being beaten by both FAHs. Even stranger, one FAH is getting significantly more clock cycles than the other...why would that be? You can see the FAHs have a low priority.

orion456 said:

Here is prime95 running as a foreground object being beaten by both FAHs. Even stranger, one FAH is getting significantly more clock cycles than the other...why would that be? You can see the FAHs have a low priority.

Click to expand...

Are you running p95 not as a torture test? In that case it makes sense that it is really running at same priority as smp ... the difference is that p95 only uses 1 core.

I would guess that the interprocess part of smp that syncs up the 4 cores is what is causing p95 to not get full share.

If you run p95 as torture test it would probably run normal priority and consume ~ 50% ie 1 core with its one thread. Run 2 p95's with affinity set to each cpu respectively in torture test mode and it will prolly take ~ 100%.

Running p95 in background (not stress testing) would be similar to running other DC projects in background. I doubt many compute heavy once coexist very well (ie evenly) which is why most DC projects are not recommended to be run on same rig as folding.

pscout said:

Are you running p95 not as a torture test?

Click to expand...

It's running as a torture test in the foreground so it has every right to be at 100% or 50% for two cores. Now why would a foreground object be given a lower priority than two background objects (FAHs) that have priority zero.

This also happens with my video editing program Studio 10. Unless I turn the FAHs off they take priority and give Studio 24%. With no FAHs, Studio gets 70% or more.

My Dell 520 at work is the same way. I kept wondering why certain activities like opening IE take so long. Turning off FAH speeds things up.....not good.

Task manager reports FAH at low regardless of whether you configured it at idle (0) or low (96) and Prime95 runs at low. THey should interfere with each other and do. I do not know the numerical priority of Prime95 but it is close to zero if not zero. Prime 95 is after all designed to crunch numbers in the background. If priority on FAH is set at low (96 in config), I'd expect FAH to rob most of the cpu cycles from EDIT: Prime95. That would be the normal behavior of FAH.

ChasR said:

Task manager reports FAH at low regardless of whether you configured it at idle (0) or low (96) and Prime95 runs at low. THey should interfere with each other and do. I do not know the numerical priority of Prime95 but it is close to zero if not zero. Prime 95 is after all designed to crunch numbers in the background. If priority on FAH is set at low (96 in config), I'd expect FAH to rob most of the cpu cycles from FAH. That would be the normal behavior of FAH.

Click to expand...

So a program in the foreground and background have the same priority? I would have thought foreground objects would receive a much higher priority.

FAH is set to priority=1, I don't know the priority of Prime95.

Having the app running in an open terminal window doesn't mean the app is running at a higher priority.

ChasR said:

Having the app running in an open terminal window doesn't mean the app is running at a higher priority.

Click to expand...

But Windows has a setting to prefer foreground or background objects. I assumed that meant higher priority. Is that not correct?