[QUOTE=petrw1;511264]Always Pwr[/QUOTE]
So, what gpu-z sensor values change if anything? You can set the update rate faster than normal.
For a GTX1080Ti, full on to full off of prime95 gave little or no effect here.

Another comparison. By coincidence, I'm also running large P-1 factoring on mprime at the moment on all four cores of a Ryzen 3 2200G. No hyperthreading available on that processor. But there is no difference in mfaktc performance, whether mprime is running or not, and I checked during both stage 1 and stage 2, no effect in either case.

Now, if I stop mfaktc, there's no effect on mprime stage 2. I didn't remember to test it during stage 1, and now it'll take a while until it's there again... :smile: but I think I saw a slight effect on LL performance back when I tested it.

Then temperatures. Ambient +21C, GPU is running at +68C while being power limited to 240W, CPU is +78C running stage 1, and +67C running stage 2.

Looking at mfaktc config...
 

I see 3 parms that mention CPU; none seem like they should make a difference:


# Set the number of data sets which can be preprocessed on CPU. This allows
# to tolerate more jitter on runtime of preprocessing and GPU stream
# runtime.
# Don't be too greedy with this value, high values are usualy just a waste
# of memory.
#
# Minimum: CPUStreams=1
# Maximum: CPUStreams=5
#
# Default: CPUStreams=3
CPUStreams=3


# allow the CPU to sleep if nothing can be preprocessed?
# 0: Do not sleep if the CPU must wait for the GPU
# 1: The CPU can sleep for a short time if it has to wait for the GPU
#
# Default: AllowSleep=0
AllowSleep=0


# enable or disable GPU sieving
# SieveOnGPU=0: use the CPU for sieving factor candidates (high CPU usage)
# SieveOnGPU=1: use the GPU for sieving factor candidates (very low CPU usage)
# GPU sieving is supported on GPUs with compute capability 2.0 or higher.
# (e.g. Geforce 400 series or newer)
#
# Default: SieveOnGPU=1
SieveOnGPU=1

Sensors
 

[QUOTE=kriesel;511270]So, what gpu-z sensor values change if anything? You can set the update rate faster than normal.
For a GTX1080Ti, full on to full off of prime95 gave little or no effect here.[/QUOTE]

I waited about 5 minutes after I stopped P-1 to recapture the sensor images:

[QUOTE=petrw1;511279]I waited about 5 minutes after I stopped P-1 to recapture the sensor images:[/QUOTE]

Something very odd... Your GPU load is nowhere near 100% even with P-1 stopped?

[QUOTE=petrw1;511279]I waited about 5 minutes after I stopped P-1 to recapture the sensor images:[/QUOTE]
FYI, GPU-Z is resizable, so all the sensors available from it can be captured in one screen shot. (It also has logging capabilities, and time resolution to 0.1 second sampling interval.)

In Windows, it seems the faster the gpu card, the harder it is to get the gpu-z reading of gpu core usage by mfaktc up to near 100%. There are certain overhead activities, such as display output, writing checkpoints, reading and modifying the worktodo file, and perhaps others, that may interfere with full gpu utilization. Running more than one instance of mfaktc can help. (Instance B can use the gpu while instance A is waiting on worktodo read for example.) Running higher bit levels and lower exponents makes each class and assignment take longer and reduces some of that overhead. Using ramdisk or SSD are recommended for the really fast assignments, or moderately fast assignments on very fast gpus. I encourage people to run TF on exponents near the wavefront in preparation for P-1 for subsequent primality testing. What I get for these are currently ~93M, and starting bit levels usually 73-75. Such assignments take ~1/2 hour to 2 hours on a GTX1080Ti, so would be ~10 to 40 minutes on an RTX2080Ti, or ~1.6 to 0.4 classes/second, checkpoints/second, screen outputs/second.

Some linux partisans report the underutilization with a single instance is not an issue in linux.

If the gpu is power limited or thermally limited, it's not clear how much it matters what the indicated %gpu core utilization is. Better system cooling will help raise the throughput bound if thermally limited.
But, as I recall, some recommend downclocking the gpu memory in TF, making more power available to the gpu cores, since TF uses little memory access.

[QUOTE=kriesel;511287]In Windows, it seems the faster the gpu card, the harder it is to get the gpu-z reading of gpu core usage by mfaktc up to near 100%.
[...snip...]
Some linux partisans report the underutilization with a single instance is not an issue in linux.[/QUOTE]
Even I, as a Linux partisan, wouldn't put the blame on Windows here, for such a big gap below 100%. I'm running my RTX 2060 under Win7, and it was 95% before putting in that GPUSieveSize=2047 magic. RTX 2080 under Linux was 94% in the same situation, but now both are about 99% only dropping below that if the work unit is really short, maximum a few seconds per exponent. But petrw1 said 1.5 seconds per class, so that shouldn't be a problem?

Attached are GPU-Z graphs for the RTX 2060, GPUSieveSize at 128.

[QUOTE=kriesel;511287] If the gpu is power limited or thermally limited, it's not clear how much it matters what the indicated %gpu core utilization is. Better system cooling will help raise the throughput bound if thermally limited.
But, as I recall, some recommend downclocking the gpu memory in TF, making more power available to the gpu cores, since TF uses little memory access.[/QUOTE]

Hmm that is true, if the usage % is higher then the card will just throttle clock speed to keep the power or temperature under the limit.

From what I've seen while testing with various clock speeds, fan speeds and temperatures, there is a point at about 50-55C after which power draw at a certain clock frequency really rises fast. I was able to increase the RTX 2080 clock speed by three steps (45 MHz) just by taking better care of case airflow and raising the GPU fan speeds. So 1800 to 1845 MHz while the total power draw remained the same, and GPU temperature dropped from 76C to 68C. The less you need to go over 60C, the better.

GDDR6 is less power hungry than GDDR5 (by about 35%) so that is less of an issue now, but of course any small gain helps.

[QUOTE=nomead;511293]I'm running my RTX 2060 under Win7, and it was 95% before putting in that GPUSieveSize=2047 magic.

Attached are GPU-Z graphs for the RTX 2060, GPUSieveSize at 128.

.[/QUOTE]

Config says 128 is the max.

What is the secret with 2047 magic and why then are you back to using 128?

How do I change PerfCap reason? Or should I not?

Thx for your help

[QUOTE=kriesel;511287]
Some linux partisans report the underutilization with a single instance is not an issue in linux.[/QUOTE]There seems to be some correlation between their belief, that it must be a problem with Windows, and their gpus on linux being of order GTX1050, rather than GTX1080 and faster. Underutilization in a single instance of mfaktc of gpu cores on GTX1050Ti is not much of an issue in Windows. Following is a GTX1050Ti in a Windows 10 laptop; 97%@1, 99% @2. (All cpu cores and the igp are also fully utilized in prime95 and mfakto respectively.) For contrast, a discrete GTX 1050Ti in a Win7 workstation runs 98-99%@1 instance, in the same room.
[CODE]C:\Users\kkrie\Documents\mfakto-uhd630>"c:\Program Files\NVIDIA Corporation\NVSMI\nvidia-smi.exe"
Thu Mar 21 01:41:02 2019
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 398.36 Driver Version: 398.36 |
|-------------------------------+----------------------+----------------------+
| GPU Name TCC/WDDM | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 GeForce GTX 105... WDDM | 00000000:01:00.0 Off | N/A |
| N/A 79C P0 N/A / N/A | 231MiB / 4096MiB | 99% Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 7408 C ...ts\mfaktc-gtx1050ti\2\mfaktc-win-64.exe N/A |
| 0 11216 C ...ents\mfaktc-gtx1050ti\mfaktc-win-64.exe N/A |
+-----------------------------------------------------------------------------+

C:\Users\kkrie\Documents\mfakto-uhd630>"c:\Program Files\NVIDIA Corporation\NVSMI\nvidia-smi.exe"
Thu Mar 21 01:41:28 2019
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 398.36 Driver Version: 398.36 |
|-------------------------------+----------------------+----------------------+
| GPU Name TCC/WDDM | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 GeForce GTX 105... WDDM | 00000000:01:00.0 Off | N/A |
| N/A 79C P0 N/A / N/A | 154MiB / 4096MiB | 97% Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 11216 C ...ents\mfaktc-gtx1050ti\mfaktc-win-64.exe N/A |
+-----------------------------------------------------------------------------+[/CODE]A GTX 1080 Ti though, 95% @1 instance, 98% @2. All of these are with the standard mfaktc v0.21 (no recompile for larger max GPUSieveSize)[QUOTE=petrw1;511297]Config says 128 is the max.

What is the secret with 2047 magic[/QUOTE]Edit source, recompile. Or find a posted executable where someone else did. [URL]https://www.mersenneforum.org/showpost.php?p=508680&postcount=116[/URL] Or wait for the increased limit to be part of a future release.[QUOTE=petrw1;511297]
How do I change PerfCap reason?[/QUOTE]I think that is readonly, produced by the gpu firmware, displayed by gpu-z or other utilities, at least directly. You can influence it indirectly by load, cooling improvements, over vs. under clocking memory clock or fan-curve changes etc through utilities like MSI Afterburner or EVGA Precision XOC, etc.

[QUOTE=petrw1;511297]What is the secret with 2047 magic and why then are you back to using 128?[/QUOTE]
I'm not back to using 128 :smile: It was just an old GPU-Z screenshot I had done over a month ago. The secret is just recompiling, or using one of the precompiled executable files posted elsewhere. (kriesel linked to it already) After that the value in the ini file can be increased up to 2047. It just works.

[QUOTE=petrw1;511297]How do I change PerfCap reason? Or should I not?[/QUOTE]
You can't. The GPU card VBIOS decides. The four I've seen are
VRel = Reliability. Indicating perf is limited by reliability voltage.(lower than the next one)
VOp = Operating. Indicating perf is limited by max operating voltage.
Pwr = Power. Indicating perf is limited by total power limit.
Thrm = Thermal. Indicating perf is limited by temperature limit.
You can adjust the power limit a bit (nvidia-smi or MSI Afterburner or something equivalent) and also the temperature target, but there is a hard thermal limit at 88C (for RTX20xx, used to be higher). Running the GPU that hot may affect the longevity of the card already, so I wouldn't recommend it. Just keep it cool and other improvements will follow.

Hey Sid. Or Andy?

You can get more juice from that card, for a lower contribution to the global warming*, just install Nvidia Precision and play a bit with clocks and voltages.

Also, the RoG skin of GPU-Z is not the best choice, I know it looks nice, but it is far behind with the features, TechPoweUp was not able in about 5 years since I opened a ticket with them to fix a couple of bugs, to keep up with some new cards, and to make the interface scalable. I think they don't know how to do it. Take the "normal" skin (not RoG) and you will see what I am talking about.


--------
*I know you don't care about that, there at the north pole, but anyhow... In fact, I don't care about the global warming either, my issue is with the local one...