Available software for pursuing mersenne primes

[kriesel]

A couple of corrections from the previous update, a couple of clarifications

[kriesel]

Note the speed disparity of the GTX480 CUDA gpu, (at 244W), at 3.6-3.7 times the hardware performance rating of the OpenCL low power card (50W), when interpreting these values. Normalizing to equal speed hardware, gpuOwL seems to perform fastest by a comfortable margin.

[kriesel]

Here's another condensation of information I gathered along the way. Please reply here or by PM with any corrections or additions you may have.

[kriesel]

Windows has provision for detecting delays in display devices responding to it. Above a certain threshold delay, it concludes the device is hung and restarts it. Even if the gpu involved is only running math code, not a display, and may not have a display connected.
(You can find such restarts in the system event log. For example, Event ID 4101; something like "Display driver nvlddmkm stopped responding and has successfully recovered." for NVIDIA. AMD gpus are also affected.) Older gpus with low compute compatibility levels have issues with these display restarts. (For example, GTX480, Quadro 4000, which are Compute Capability 2.0) As GIMPS work advances to larger exponents, computations take longer. Windows detects a long time for the gpu to respond and interprets it as a hung device, and stops and restarts it. Unfortunately, it does this in a way that does not reconnect to existing sessions of GPU-Z or other utilities, or to CUDA applications such as CUDALucas or CUDAPm1 or mfaktc, or the opencl equivalent applications.

Historically, the applications have been wrapped in batch scripts to restart them, and adding a TdrDelay value in the registry larger than the implicit default has been recommended. However, these are incomplete solutions, that often fail. A system restart clears it up. The restart is disruptive to gpu applications running on other gpus, prime95, and anything else running on the system, and requires operator intervention to stop and restart it all.

But, there is another approach. In Device Manager, disable and reenable the errant display device to avoid a system restart. I've seen this reenable access to sensor readings of a GPU in a preexisting GPU-Z session, as well as make the gpu available again for use by a newly launched CUDA application. The system restart is avoided, allowing prime95 and other GPUs' application instances to continue uninterrupted.

Can the device disable/reenable be done from the command line or a batch script, minimizing idle time and operator intervention? Yes, using the appropriate version of devcon.exe (available in Visual Studio, the Windows Driver Kit, etc) per
https://superuser.com/questions/4290...a-command-line
https://docs.microsoft.com/en-us/win...devtest/devcon

Such a script may benefit if it includes delays between commands. Some Windows OS versions don't support the timeout command. Delays can be provided on versions where timeout generates an error, by conditional ping to a nonexistent address, padding the number of seconds wait with 3 zeros since ping timing is in milliseconds.

set delay=3
set nonexist=192.168.2.3
timeout /t %delay%
if errorlevel 1 ping %nonexist% -n 1 -w %delay%000

Another piece of the puzzle is the device id for devcon.exe in the correct form.

Another piece of the puzzle is getting the batch file containing the devcon command to run as administrator. Otherwise devcon will run at too low a privilege level and list devices but not control them, even when the batch file is launched by an account with administrator permissions. (Most online how-tos for it omit that crucial little detail.) For getting devcon to work, see http://classicshell.net/forum/viewtopic.php?f=5&t=423 particularly the requirement to create a shortcut to force the batch file to run as administrator, and https://docs.microsoft.com/en-us/win...local_computer to find the names of your gpu device(s).

So, putting the pieces together:
a) make the batch file that runs the CUDA app (CUDALucas, CUDAPm1) or OpenCl app that is affected by driver timeouts. In my experience mfaktc seems unaffected.
b) make a shortcut to the batch file, and in the advanced tab of the shortcut properties, set it to run as administrator
c) modify the shortcut to cmd /k batchfile so it sticks around after it exits and the flow can be examined
d) install devcon.exe on the system, either in the working directory of the CUDA app or in \windows\system32, or somewhere else that's in your path.
e) use devcon.exe interactively to obtain the unique device ID for the gpu to be controlled
f) modify the batch file to use the unique device ID obtained, in the disable and enable lines, and adjust other settings as needed. Be sure to use enough of the id that it identifies a unique gpu device matching the CUDA device number affected.
g) test
h) make adjustments to TDR related registry settings as needed; increasing TDRDelay helps some; increasing TDRDdiDelay may also help. See https://docs.microsoft.com/en-us/win...-registry-keys for the list and defaults
i) use and enjoy

Draft batch file, to be run from the high-privilege shortcut:

set delay=1
set maxdelay=10
set count=0
set countmax=5
set exe=cudaPm1_win64_20130923_CUDA_55.exe
set model=GeForce GTX 480
set dev=1
set nonexist=192.168.2.3
cd "\Users\ken\My Documents\cudapm1"
echo worktodo.txt >>cudapm1.txt
goto loop
: change the above set commands etc to suit your situation and preferences
: following is what does the production work, from the worktodo file, putting results in the results file and appending history in the cudapm1.txt log file
: limited looping may be useful in some cases (such as Windows TDR events); too high a count or no limit mostly pointlessly inflates log size, especially if worktodo is emptied

:loop
echo batch wrapper reports (re)launch of %exe% on %model% at %date% %time% reset count %count% of max %countmax% >>cudapm1.txt
title %computername% model %model% %exe% dev %dev% reset count %count% (%0)
%exe% -d %dev% >>cudapm1.txt
echo batch wrapper reports exit at %date% %time% >>cudapm1.txt
echo attempting disable/enable cycle on gpu device >>cudapm1.txt
devcon disable "PCI\VEN_10DE&DEV_06C0&SUBSYS_14803842" >>cudapm1.txt
devcon enable "PCI\VEN_10DE&DEV_06C0&SUBSYS_14803842" >>cudapm1.txt
timeout /T %delay%
if errorlevel 1 ping %nonexist% -n 1 -w %delay%000
if %delay% lss %maxdelay% set /A delay=delay*2
if %delay% gtr %maxdelay% set delay=%maxdelay%
set /A count=count+1
if %count% lss %countmax% goto loop
echo at %date% %time% countmax=%countmax% reached, exiting batch file

[kriesel]

I was offered "a blog area to consolidate all of your pdfs and guides and stuff" and accepted.
Feel free to have a look and suggest content. (G-rated only;)
General interest gpu related reference material http://www.mersenneforum.org/showthread.php?t=23371
That links to several application-specific reference threads.
Future updates to material previously posted in this "Available Software" thread will probably occur on the blog threads and not here. Having multiple threads and in-place update makes it more manageable.

[heliosh]

Originally Posted by VBCurtis

How does GPU-ecm help do anything with mersennes? All Mersennes small enough for GPU-ecm to work are already fully factored.

gpu-ecm can still be used for partially factored mersenne-numbers with small enough composites like M1217, for which I'm just giving a try.

[kriesel]

Originally Posted by heliosh

gpu-ecm can still be used for partially factored mersenne-numbers with small enough composites like M1217, for which I'm just giving a try.

Have fun. gpu-ecm has its uses, in the small exponents. As does ecm in mprime/prime95 (up to ~20M exponents) which I'm running now.

The discussion about what to include or not in the list of available software led me to clarify my purpose for creating the thread, in http://www.mersenneforum.org/showpos...0&postcount=10
(The spectrum of on-topic, tangential, and off-topic is common, so no problem there.)
The person you responded to correctly perceived early my initially unclearly stated intent; to find and tabulate software for productive use at the wavefront of efforts to find new Mersenne primes, which are now in the tens of millions of bits exponent and above.

gpu-ecm as far as I know is limited to 4K bit exponents. For that reason, I've listed gpu-ecm in the last section of the available software table. (not suitable for pursuing a big new Mersenne prime, not included)

[kriesel]

The Available Mersenne hunting software list has been updated in post two of http://www.mersenneforum.org/showthr...291#post488291

[kriesel]

Originally Posted by kriesel

The Available Mersenne hunting software list has been updated in post two of http://www.mersenneforum.org/showthr...291#post488291

Added gmp-ecm, updated various table entries

Originally Posted by kriesel

Added gmp-ecm, updated various table entries

It would be nice if we could adapt Kunde21/MersenneManager to send/receive PRP results and to extend it to work with many instances of mersenne prime search program.

[kriesel]

Originally Posted by kriesel

The Available Mersenne hunting software list has been updated in post two of http://www.mersenneforum.org/showthr...291#post488291

While you're there, look around at some of the other reference information gathered