GUIDE: ATI Client - Lower CPU % + Raise PPD

Status
Not open for further replies.

EvilAlchemist

2[H]4U
Joined
Jan 11, 2008
Messages
2,730
Things you will need:

  • Catalyst 9.4 Drivers
  • Vista (X86 or X64)
  • 5 minutes

Here are the available environment Variables:
  • CAL_NO_FLUSH
  • CAL_PRE_FLUSH
  • BROOK_YIELD
  • FLUSH_INTERVAL


mhouston-->FoldingForum.org said:
FLUSH_INTERVAL is the one that is going to effect GFX performance. Basically, it corresponds to the number of functions submitted in one shot to the GPU. The GPU will not do anything else, including UI updates, until that submission completes. A lower value will basically reduce the timeslice folding@home gets on the GPU, but UI and graphics responsiveness will improve. However, as the value gets smaller, the CPU/OS/Driver overheads increase, so there is a tradeoff between folding@home performance and UI 'snappiness'.

CAL_NO_FLUSH and CAL_PRE_FLUSH, which were poor name choices by me, change how things are submitted to the hardware. CAL_NO_FLUSH changes how we build up packets of work to submit to the hardware. CAL_PRE_FLUSH basically 'double buffers' the building of command buffers so one can be processed while another is being built.

BROOK_YIELD has several modes, 0/1/2. 0 will spin the CPU giving the lowest latency response to the GPU as possible. 1 will yield the CPU when waiting on the GPU to complete to any process of the same priority. 2 will yield the CPU to any process. Now, for really small flush intervals and small proteins, there is a chance the GPU was almost done when the CPU yields. You have to wait to be rescheduled, which could be up to a millisecond. A fast GPU completes many of the kernels in <100 microseconds, so this can have a large impact. If you have a larger flush interval, you can build up several milliseconds of work so missing by a bit is less of an issue.

Step 1: Stop the F@H ATI GPU client.

Step 2: Install Catalyst 9.4 Driver Package

Step 3: Go into the F@H "start in" directory (Where you work folder & config files are)
Delete the 3-5 ATI .dll files.

Step 4: Right click "My Computer" --> Advanced / Environment Variables -->
System Variables - New - "Add parameters and settings for each one".

Here are my settings for my ATI 4850:
CAL_NO_FLUSH=1
CAL_PRE_FLUSH=1
BROOK_YIELD=2
FLUSH_INTERVAL=96

atienvriomentvar.gif


Step 5: Restart the system (Not 100% necessary but never a bad idea)

Step 6: Relaunch the client

atienvriomentvar2.gif


You are done. Your CPU usage on the ATI client will be much lower.
 
wow.. nice work.. hmm maybe my 4870 wont be collecting dust anymore..

what kind of effect does this have on PPD?
 
Dude, this rocks!!! Do you know if it will work on a machine that has Dual ATI 4870 cards?

Yeah, I'd like to know what kind of an effect this has on PPD.
 
Using those settings causes my 4870 to EUE constantly. I will try setting a larger flush interval.
 
Using those settings causes my 4870 to EUE constantly. I will try setting a larger flush interval.

Zero .. Try this ..

  • Set the CAL_NO_FLUSH=1 and run the client.
  • If stable, then add CAL_PRE_FLUSH=1
  • If stable, then add BROOK_YIELD=2
  • The last one you should add is FLUSH_INTERVAL

I *think* the default FLUSH_INTERVAL is 16

First try a low setting that is divizable by 2 - so 16 then 32 then 64 ..

I would suggest not going to high - 96-128 seems to be the top out
The other suggestion is to take out CAL_PRE_FLUSH and run FLUSH_INTERVAL=256.

Also make sure you did delete all the .dll files in the F@H directory.
That will also cause EUE's .....

It is also *SUPER* important you are running Cat 9.4.....
 
I'm using a FLUSH_INTERVAL of 128, and it seems to be going alright. I'm seeing a small increase in PPD as well.
 
I'm using a FLUSH_INTERVAL of 128, and it seems to be going alright. I'm seeing a small increase in PPD as well.

Using CAL_NO_FLUSH=1 your PPD will keep going up.

It takes a few % to get the GPU really going ...

Let me know if you have any more issues ..

I have been running these setting for going on 3 months .. so I know they work with 100% stability.

Lowering the FLUSH_INTERVAL helps stability .. not raising .. the lower that #, the smaller the data packet size ..
 
that is awsome, i hated running 2 vm;s and the ati client cause of one core being pegged %100 lal the time by the GPU client.
 
TRying this out. My 4890 has been hogging more than 1 core of a Phenom II at 3.5Ghz.
 
Looks like I spoke too soon. Got another EUE, and now I'm stuck waiting for work (not getting any).
 
I forgot to check my ppd before I made the changes, but I'm currently getting ~3040 ppd from a 511 point 5734 unit on my 4890 @ 900 Mhz. My CPU usage is way way down from pegged at 100% to around 70-75%(with 2 cores running a VM). THe single VM I have on my x3 CPU went from 11-11.5 minutes per % to 9.5. Now I can feel comfortable adding a couple more 4890s on to this rig without upgrading the CPU.
 
I forgot to check my ppd before I made the changes, but I'm currently getting ~3040 ppd from a 511 point 5734 unit on my 4890 @ 900 Mhz. My CPU usage is way way down from pegged at 100% to around 70-75%(with 2 cores running a VM). THe single VM I have on my x3 CPU went from 11-11.5 minutes per % to 9.5. Now I can feel comfortable adding a couple more 4890s on to this rig without upgrading the CPU.

Awesome .. just make sure to check it to make sure you have no EUE like Zero.
I don' think you will , but there is several change we can make to fix that issue.
 
Hmm... Good stuff! Will try it when I get home from work. Hopefully it won't break anything else as that PC is my gaming rig.
 
No EUEs yet on either the GPU or the VM. Looks like it is working. I still need to figure out why it is producing about the same ppd at 900 Mhz as a 4870 at 790.
 
flogge, mind telling me exactly what variable settings you're using? I still haven't been able to get it stable.
 
Figures... Get home and do the changes only to find I can't get another work unit. LOL

LOL .. yeah ... mine can't seem to get work as well

Stanford is aware of this issue and it was posted about 4 days ago as a schedule down time for the Assignment Servers.

Hopefully they will come back online soon.
 
I used exactly the same variables as Evil posted initially for his 4850s. Please don't take this wrong because I've had some "doh" moments worse than this, but you want to put the variable name, ie: "CAL_NO_FLUSH" in one box and the value, ie "1" in the other box when you create the new variable.
 
I used exactly the same variables as Evil posted initially for his 4850s. Please don't take this wrong because I've had some "doh" moments worse than this, but you want to put the variable name, ie: "CAL_NO_FLUSH" in one box and the value, ie "1" in the other box when you create the new variable.
I was doing it right. It seems like there's just some kind of incompatibility that's preventing it from working.
 
So far so good! *knocks on particle board*

Don't know about the PPD but it's noticeably faster through each % and is only using ~10% CPU now as opposed to a whole core.

(4870 1GB btw)
 
Mine had a few EUEs earlier today before it even completed 1%. It hit the limit and I just restarted it. It is not finding new work so I'll check it in the morning. Hopefully it was the AS problems or bad units rather than the GPU itself because it completed several work units with the new settings before it started giving fits.
 
Reduced flush interval to 64. Work server hates me right now so I only got 1 WU since last night. It completed with no problems.
 
Reduced flush interval to 64. Work server hates me right now so I only got 1 WU since last night. It completed with no problems.

Yeah, Stanford is still having some issues with the Assignment Server.
I am having the same issue getting work.

At least Zero got his up and running now ... :cool:

I have found that FLUSH_INTERVAL = 96 is the best on my systems, but your results may very. I know that 128 was too high so after 5 hours of working with mhouston, we figured out 96 was optimal for my setups.

In the future, this will be set by the WU and a manual setting will not be necessary.
For now, we have to deal with setting these options.
 
It turns out that I was running the older 1.22 core, so that was causing the EUEs. It didn't download 1.24 for some reason, so I deleted it manually and now it's running fine with 1.24. I've added all of the variables and it appears to be working, although my CPU usage is still somewhat high (30-50% of one of my cores).
 
(30-50% of one of my cores).

Is that with BROOK_YIELD = 2?

If so, that is really weird ..... it should be around 1% - 5% ??

Correction: Project 5650 and similar units do use more % of CPU .... just wait and see when you get a 511 pointer
 
Is that with BROOK_YIELD = 2?

If so, that is really weird ..... it should be around 1% - 5% ??

Correction: Project 5650 and similar units do use more % of CPU .... just wait and see when you get a 511 pointer
It is with BROOK_YIELD=2. It shows up as around 2-7% CPU usage in Task Manager, but since I have a quad-core that means that it's actually using 8-28% of one core. I changed my FLUSH_INTERVAL to 128 and that brought it down a bit, so now it's staying mostly in the mid-20s. This is with a 511-point unit, by the way.
 
So I've been running the client with these variables since yesterday morning and everything appears fine. My PPD is still lower than it was before even with the variables set, because the 1.24 core added some more math. However, that's more than compensated for the fact that I can now run a second Linux VM on my CPU, which gives me an extra 3000PPD or so. I've had to manually increase the priority of the GPU core though (through Bill2's Process Manager) to prevent the VMs from stifling it, but with that set up I'm getting very stable production.
 
cool thanks now i can run the smp with this and increased my ppd

 
So I've been running the client with these variables since yesterday morning and everything appears fine. My PPD is still lower than it was before even with the variables set, because the 1.24 core added some more math. However, that's more than compensated for the fact that I can now run a second Linux VM on my CPU, which gives me an extra 3000PPD or so. I've had to manually increase the priority of the GPU core though (through Bill2's Process Manager) to prevent the VMs from stifling it, but with that set up I'm getting very stable production.


nice.. good to see ya got it working smoothly..
 
One thing I noticed is that with 384 point WU will have a reduced PPD but the larger WU have a higher PPD now.

 
Status
Not open for further replies.
Back
Top