Improved workload tuning

[me.scotty]

There are currently three parameters for tuning the GPU load - GPU-Accel (workload tuning), GPU-Loops, and (for plus) segment size.

While I'm sure all of these are quite meaningful for those familiar with the intricacies of GPU architecture, they are much less so for regular folks.

I recently updated from a GTX560 to a HD6990.
For a given test case using the same tuning parameters, both GPU's go to 99% load. (Don't know if they're working efficiently, but they're busy...)
The GTX560 runs at a quite 82C, whereas the HD6990 sounds like a jet engine at 92C.

Here's what I would like to see.

Suggestion #1 - Allow the user to simply input GPU load, as a percentage. The application would chose efficient values for the tuning parameters, based on the attack type, etc., adjusting at runtime to meet the selected load.


Also, my experience above showed the rather abrupt exit (exception thrown?) when exceeding the watchdog temp, which also didn't seem to fully clean up (there was a file with a ".new" extension.)

Suggestion #2 - Instead of a rather inelegant abort, the application should "dial back" it's load to keep it within the selected temperature.


Alternative to the above - add tuning parameters "best practices" to the wiki.

Thanks for all the great work.

[radix]

Ummm what.....why would you want anything but full speed? Tuning options change depending on the hash type as well. It would be quite a feat to have "auto tune" added since there are a million different variables for every card per hash type. What you should be doing is finding out what works best for what and using those. If heat is an issue (and 6990's tend to set houses on fire) upgrade your cooling solution. The HSF that comes with these are not really ment for compute.

[me.scotty]

Ummm what.....why would you want anything but full speed?

Single card configurations on non-dedicated machines?

...since there are a million different variables for every card per hash type...

Sounds like the perfect situation for a computer program...

[KT819GM]

It was already talked about GPGPU applications and GPU temperatures. Simply - it's too risky to leave temperature control for application witch is not intended for that. Even AMD driver does not control everything like it should do in perfect conditions. Also like radix told already - factory cooling is not intended to be used on full load 24 hours.

p.s. if for real one HD6990 with downclocked ram on stock clocks runs normally @60% fan not reaching 70C at ambient ~23C.

p.p.s. did you noticed that AMD engineers did 'super' solution witch blows hot air in both directions, so case have to be prepared for heat spreading.

[atom]

Suggestion #1 - Allow the user to simply input GPU load, as a percentage. The application would chose efficient values for the tuning parameters, based on the attack type, etc., adjusting at runtime to meet the selected load.

well, the idea is good. but the reality is so different. for example, manually adjust oclHashcat to run only with 90% gpu utilization. you can start playing fps hungry games in background without loosing frames. i think the gpu utilization meter is to inaccurate.

Suggestion #2 - Instead of a rather inelegant abort, the application should "dial back" it's load to keep it within the selected temperature.

absolutly not. this would create an huge code overhead. also, every user wants it different. no, just find your acceptable utilzation manually. you will notice there is some point the temps will not exceed, regardless of the time.

[me.scotty]

Looks like support for these is rather minimal.
If at some point in the future that changes, I can offer some implementation suggestions.

1) Selecting a GPU load percentage seems fairly trivial.
At startup, after retrieving the GPU capabilites (# of shaders), simply scale and use that number.
All this assumes is that # of shaders is an input to some function in the application.

2) Optimizing "workload parameters" is worthy goal only if they have a significant effect on efficiency.
For this to work, it would be best if they can be formulated into a linear equation with independent parameters, a convex solution (no local maximums), with Hashes/s as the output.
After reaching something of a steady state, "tweak" each parameter (up and down) to maximize Hashes/s.
A separate thread can handle this, but it assumes that the parameters can be adjusted after startup.

3) Scaling back a GPU so it doesn't exceed a maximum temperature is a simple feedback and control system, similar to the heater thermostat on your wall.
This would require a monitoring thread (in Java I'd implement it as a repeating timer that fires an event every 0.5s or so).
If the maximum temperature is approached, scale back the number of available shaders.
As before, it assumes that the application architecture uses something like a job queue, where the number of workers (i.e. shaders) can be changed at run time.
And it assumes that the temperature reading from the GPU is accurate.


My $0.02
Thanks for your consideration.

[atom]

1) Selecting a GPU load percentage seems fairly trivial.
At startup, after retrieving the GPU capabilites (# of shaders), simply scale and use that number.
All this assumes is that # of shaders is an input to some function in the application.

no, you can not scale at runtime when you are developing for performance.

2) Optimizing "workload parameters" is worthy goal only if they have a significant effect on efficiency.
For this to work, it would be best if they can be formulated into a linear equation with independent parameters, a convex solution (no local maximums), with Hashes/s as the output.
After reaching something of a steady state, "tweak" each parameter (up and down) to maximize Hashes/s.
A separate thread can handle this, but it assumes that the parameters can be adjusted after startup.

no, it can not, see my original post. its about the 90% thing.

3) Scaling back a GPU so it doesn't exceed a maximum temperature is a simple feedback and control system, similar to the heater thermostat on your wall.
This would require a monitoring thread (in Java I'd implement it as a repeating timer that fires an event every 0.5s or so).
If the maximum temperature is approached, scale back the number of available shaders.
As before, it assumes that the application architecture uses something like a job queue, where the number of workers (i.e. shaders) can be changed at run time.
And it assumes that the temperature reading from the GPU is accurate.

this is implemented by the driver. it automatically clocks down if some threshold is reached.

[ntk]

@me.scotty, maybe there is already something you can use to get the best stable values in heavy loaded condition for your machine first, then you can run Atom's program.

Try CGminer . It has an auto parameter setter (GPU freq, RAM freq) base on chosen best load, temperature. You do what ever for the best available cooling first, then run that program. That program takes care of the rest, trying the highest load, by keep temp low as possible. So over a few hours, or when you want a day or so, you have best lowest temp, paired with best load, best GPU value, lowest RAM freq.
<http://bit-coin-trading.com/forum/index.php?topic=266.0>
Use that I found my runs best several nights at GPU/RAM freq 913, 650 at temp 82 degrees Celcius, I used to set aticonfig --odsc=900,1100 following s.o's instruction on internet

"this is implemented by the driver. it automatically clocks down if some threshold is reached." that is true if too much over clocked. ATI just hits the breaks even when your still runs.

U need to find the best possible to set fix, if less work load ATI automatic scales down. No need to cause extra work load by continuosly adjusting.

[ntk]

Sorry I don't want to advert for b-coin. Only want to point out, there is already an similar implementation, open source.

[me.scotty]

this is implemented by the driver. it automatically clocks down if some threshold is reached

In my case, I got a hard crash (exception) inside oclHashcat, leaving an intermediate file (.new)
This might due to the 11.4 Catalyst I'm using.
I've been reluctant to update because of the past cautions...

Try CGminer

Thanks for the suggestion. This looks promising.
With my current setup (11.4 Catalyst, single card), when I'm running oclHashcat, I can do simple web browsing, file editing, etc. without problem.
However, if I try to watch a video, I get an immediate screen lockup (GPU activity goes to zero, based on the fan noise), which can only be resolved by a hard reboot. Not so good.