"mixed" NVIDIA perfomance level with GTX 970

[mattifolder]

I've a wired effect at gpu folding with my GTX 970. All tools under windows 7 and Linux Mint 16 Mate 64 bit showing perfomance level 2 at folding. That isn't such a problem, but so the VRAM clock is only at 3005Mhz instead factory default P0 level's 3500MHz. The GPU core clock inclusive boost ist changed correctly. In windows 7 (driver 344.48) it is possible to change P2-VRAM-clock by NVIDIA Inspector tool, nvidia's linux tool nvidia-settings (driver 343.22) can't change P2-VRAM-clock. It seems, the performance level isn't only shown incorrect, it don't change correctly at start of gpu folding client. At the moment I can only confirm the problem for core 17 project, but i think it was the same with core 15. In windows 7 I tested GPU with MSI combustor, the performance level changes correctly to performance level P0 (not P2), gpu and (!) vram clocks changing correctly. Other members of our folding team had seen the same effect. May be a problem of grafic driver, folding core and client or all together. Is the problem known here, are there already known activities at pande group (or nvidia) ?

[bruce]

You are the first to report it here.

I suppose one way to figure out if it's the drivers is to try a different version. Has anybody doen that yet?

[billford]

I read the OP and went off to look at mine… very similar.

GTX 980, Ubuntu 14.04, 343.22 drivers, performance level at 2.

The graphics clocks are the same for both P2 and P3 but the memory clock is 6,008MHz for P2 and 7,010MHz for P3. Mode is set to Adaptive, maybe the driver has determined that memory speed isn't critical for FAH so doesn't move to the higher setting?

Setting the mode to "Prefer higher performance" didn't change anything, but according to the mouse-over it only "hints", it doesn't "instruct".

It sure doesn't seem to make any difference to the way it goes, but perhaps it would with a more memory intensive application such as a game? I don't have any so can't tell.

[billford]

Hmmm… just out of curiosity I watched it as it finished one WU and started another.

When the WU reached 100% it went briefly to P3 (a second or so) then dropped back to P2. If there's a large transfer of data (a sort of "core dump") from the gpu at this point, this could make sense.

It didn't drop below P2 but that may have been a matter of time- when I tried a pause it took some time to drop below P2, longer than the interval between finishing one WU and starting the next.

[mattifolder]

I suppose one way to figure out if it's the drivers is to try a different version. Has anybody doen that yet?

The same effect with 344.48 and 1st for big maxwells (344.16). Older versions should not detect GM204 GPU's.

maybe the driver has determined that memory speed isn't critical for FAH so doesn't move to the higher setting?

It makes appreciable difference of TPF.

[billford]

It makes appreciable difference of TPF.

I've never looked for that effect so can't really comment much, but I don't recall noticing any difference when I underclocked the memory on a 780 Ti by 2,000MHz (Linux).

I did run it on Windows for a while, iirc the memory bandwidth usage was less than 20% so I wouldn't have expected the speed to make a significant difference to TPF.

But I'm quite prepared to be proved wrong

[mattifolder]

It surely depends from projects, core_17 project with nvidia have nearly every 5 minutes a greater activity of cpu. I think, at least at these moments the troughput of video memory is more important. In my system one core of the i7-3770K@4.4HGHz with core_17 project is also working all the time for gpu folding core. So there would be permanently data moved between gpu and cpu.

[Joe_H]

The constant use of CPU by Core_17 is an artifact of the way nVidia implements OpenCL in their drivers. The greater usage every few minutes is the folding core performing data validation and checkpointing on the CPU. The constant CPU in between is not an indication of constant data movement.

[bruce]

maybe the driver has determined that memory speed isn't critical for FAH so doesn't move to the higher setting?

It makes appreciable difference of TPF.

How long did the WU run before you determined that? TPF is a long-term average and short-term values can be misleading unless you let the WU complete several new 1% frames. In my experience, a faster memory setting does increase the heat and the power draw but has very little influence on TPF. In fact, some overclockers REDUCE the memory speed to allow an additional small increase in core speed. For best thermal control, that would be consistent with an automatic increase in VRAM speed after FAH's use of the shaders has finished.

[mattifolder]

I compared complete projects with same types, that run over night under the same conditions without other interactive usage of the computer. Also I compared the average over all projects of one type. "appreciable difference" is in my view already by nearly 5 percent. At Folding the boost clock of my GTX 970 is (constanly but for shared work with cpu breaks) the same independent of the VRAM clock.
Btw, I only want to take clearness, whether the effect is wanted or a bug. And if it is a bug, I want to initiate to resolve it.

[Breach]

I can confirm that behaviour with core 15 and core 17 WUs - the cores don't make the card enter performance state 0 (P0) mode which corresponds to: P0/P1 - Maximum 3D performance. Whether the somewhat lower memory speed (in P2) has a tangible effect on tpf/ppd, or whether that's by design or not I can't say. To avoid confusion, note that max performance is not P3, but P0 this is described here: http://docs.nvidia.com/gameworks/conten ... state.html (P0 corresponds to Performance Level 3 in nvidia inspector).

[mattifolder]

Thank for corrected info about performance levels, I'll change it in start post.