Problem in Underclocking using Nvidia settings can't change the GPU freq more than once

Accelerated Computing CUDA CUDA Programming and Performance
1

Hello All,

I am student and I am using 8800 GTS (320 MB) for my research.
I am trying to achieve dynamic clocking for GPUs.

Whenever I try to change the GPU clock freq, it works the first time and after a while when I intend to change it again to another frequency, the Nvidia Settings application behaves erratically. The entire system freezes and I had to restart either the X-server or the machine.

I tried changing the frequency using “nvidia-settings -a ‘GPU3DClockFreqs=500,800’”
as well as using the GUI application provided by Nvidia (the Nvidia Setting).

Same things happen, when I use nvclock – nvclock -n 500 -m 800

So when I want to reduce the freq to 500 and then to 490, it is not possible.

To make any further progress in my research, I need to keep changing the GPU freq and monitor the system behavior for every freq. But I am stuck, coz I can’t change the freq more than once.

Is there any other applications/ways to achieve it ??
Any info would be greatly appreciated.

Additional Info :
Ubuntu 8.04 – AMD 64 Bit – Geforce 8800 GTS
nvclock installed.
coolbits turned ON
Pre-set GPU 3D freq : 513 MHz

Thanks,
krishna

2

This sounds like a known bug in 177.67 that’s already fixed in newer drivers. As you didn’t state which driver you’re using, I can’t comment further. Please note that nvclock is unsupported.

3

Thanks for the info.

I installed the new driver … NVIDIA-Linux-x86_64-177.80-pkg2.run.

When i tried to change the freq after that, I am getting the following error.

The program ‘nvidia-settings’ received an X Window System error.

This probably reflects a bug in the program.

The error was ‘BadValue (integer parameter out of range for operation)’.

(Details: serial 58 error_code 2 request_code 146 minor_code 3)

(Note to programmers: normally, X errors are reported asynchronously;

that is, you will receive the error a while after causing it.

To debug your program, run it with the --sync command line

option to change this behavior. You can then get a meaningful

backtrace from your debugger if you break on the gdk_x_error() function.)

When I used the previous version of Nvidia Driver (NVIDIA-Linux-x86_64-177.13-pkg2.run),

I first set the GPUOverclockingState=1 and then try to run nvidia-settings -a GPU3DClockFreqs=500,800.

But I couldn’t see an equivalent setting for GPUOverclockingState in the newest version (177.80) driver. Please help me regarding this.

Any help would be greatly appreciated.

4

This is clearly not a CUDA bug. I’d recommend reporting this via the mechanism documented in the display driver README.

5

Hi,

Thanks for the response.
I understand this specific problem is related to the display driver and I will go ahead post this problem in the correct forums.

But what I was hoping from CUDA in-terms of dynamic clocking was, there should be an API to dynamically change the GPU clock frequency. To be specific, as of now there is no way to set/control the GPU frequency through CUDA API or CUDA programs/commands.

I know i can use the nvidia-settings GUI API to change the clock freq, but I wish to do it through a CUDA API/program.

As there is none in Nvidia, am probing through the ATI’s APIs to achieve the same in the ATI graphic cards.

Please let me know whether there is an API available with CUDA/Nvidia to achieve the same.

Thanks

6

There is no such API call in CUDA. You can download the nvclock source code and see how they do it…

I don’t see how changing clocks dynamically would benefit a CUDA app, though. CUDA is all about getting the highest performance possible 24/7 => you always want it to run at the fastest clock.

7

is there anything in the new driver(NVIDIA-Linux-x86_64-177.80) which is equivalent to setting “GPUOverclockingState=1”.

I used to set the value to 1 and then tried to modify the GPU freq. But that option is entirely not available and i understand there must be something which replaced that ‘GPUOverclockingState’ setting … otherwise is it a bug ?