Nvidia GTX 970

I've been running a GTX 970 here for a while at 3X. I don't recall my testing details and am not sure whether I tried 4X or not, but am sure 3X was more productive than 2X.

But all my testing was on Perseus with v 1.39 code. The current work of comparable interest is Parkes PMPS. More importantly, there is a beta application out (currently version 1.52) which has dramatically helped the Einstein productivity of my GTX 970. But I have not redone any multiplicity benefit testing. Your choice of 2X is probably not very greatly different in output than the optimum.

If productivity is your main interest, then run, do not walk, to your Einstein account configuration settings for the location (aka venue) you have that host in, and enable beta test. You have chosen to hide your computers, so I can't just click on your task list to see whether you have already done so. I suggest you unhide them if you ask for assistance here.

My current GPU clock rate is a little lower than the one I used for a couple of months earlier this year when I was running Perseus on v1.39. I got five validate errors on this host on Parkes on work running on 1.50 first Beta and 1.52 second Beta code, and tentatively concluded that my particular GTX970 would not run error-free quite so fast on the new code as on the old.

I just now checked (and it has been a half dozen days since my most recent validate error) and, as logged by GPU-Z, my current GTX 970 stats are:
[pre]
multiplicity: 3X
Core clock 1427
GPU Mem clock 1949
Power 78%
GPU load 92%
Mem con load 84%
VDDC 1.20[/pre]
I show here short-term (roughly two minutes) averages as performed by GPU-Z on the parameters which displayed obvious fluctuation (power and loads). They may differ somewhat from a proper average of hours. Not by much, I suspect.

I should mention that different monitoring applications will report different memory clock rates for the same operating condition. For example nvidia Inspector describes my current operating condition as having a GPU memory clock rate of 3899.

I don't have any special advice on ways and means to run faster. I suspect the GPU core clock maximum error-free speed may be increased by higher voltage, if your control application gives you that option, and if the board actually heeds the command. Of course that condition will raise power consumption Other than that, choice of code and operating conditions may matter. You may find that running a different application will give you a higher maximum SPU clock rate than running 1.52 Parkes, though I'd personally not want to do that. I've made no observations nor heard reports regarding application impact on GPU memory clock rate maximum.

Others have given you good advice, I think, on best multiplicity--try it and see. While version 1.47/1.50 had such a range of elapsed times that a small trial would tell you little, the elapsed times are much more consistent in 1.52. In particular, a large number of the WUs fall in a base population. When all of the "parallel" tasks on the GPU belong to the base population, the elapsed time and CPU time seem to be in a very tight distribution. So I think you can make a good comparison of the improvement or harm caused by a different multiplicity by monitoring the relative ETs of each simultaneous batch of work. When all are about the same, then you probably have base population units, and you can compare the performance with the base population of a different multiplicity with simple arithmetic. Of course a really large sample will do a better job of predicting long-term performance, but I don't think we know how representative the work distributed in any given hour, day, or week is of the long-term Parkes work distribution regarding whatever it is that causes data-dependent execution performance variation. Failing that, no one can tell you how well disbursed in distribution time your work unit sample needs to be, nor how large it needs to be.

I'd say maximum core clock and memory clock rate setting is somewhat similar--best advice is "try and see". There is no good reason to expect that someone else's sample of a GTX 970 card will top out at the same maximum clock rates as your sample, nor that the failure syndrome when you go faster than it will work will be the same.

Good luck.

Well, that is not news. The desire to raise memory clock in the P2 state was the whole reason I downloaded Nvidia Inspector pursuant to suggestions on this forum.

How are you handling fan speed, and what temperature is your GPU reporting shortly before you have system failure?

For reasons particular to a non-performance aspect of my operations, I tend to run my GPU fans at fixed rates. For my GTX970, I currently intend to run at 55%, though I am not sure that is properly in place.

While it is highly likely the GPU will run correctly at a somewhat higher core clock rate if kept a bit cooler, I don't know what influence the GPU fan speed and reported temperature have on survivable GPU mem clock rate, but doubt it is zero.

I use NvidiaInspector to set the P2 clock +100Mhz so that I run the memory at 3605Mhz for my 970s. I use SIV to set the maximum GPU temp to 65C by having SIV modulate the fan speeds. I run 6 CPU tasks and 3 tasks per GPU and that keeps the system running around 92% CPU utilization and around 99% GPU utilization with no errors and no downclocks or reboots in the systems. I recommend SIV for controlling the GPU and also for system monitoring.

Cheers, Keith