CUDALucas (a.k.a. MaclucasFFTW/CUDA 2.3/CUFFTW)

[mognuts]

Originally Posted by flashjh

Windows r56 executables posted to SourceForge

r56 just successfully completed double check of 31010747.

[mognuts]

Originally Posted by mognuts

r56 just successfully completed double check of 31010747.

Through the run I had a couple of these, but it didn't affect the result, or cause the drivers to stop working.

|  Dec 26  22:33:05  |  M 54297883   2820000  0xa5d98db4daef2036  |  3136K  0.06641   5.3687   53.68s  |  3:04:59:19   5.19%  |
|  Dec 26  22:33:59  |  M 54297883   2830000  0x4a7f94d8efb62886  |  3136K  0.06641   5.3695   53.69s  |  3:04:58:22   5.21%  |
|   Date     Time    |  Test Num     Iter         Residue         |   FFT    Error    ms/It     Time   |       ETA     Done   |
|  Dec 26  22:34:53  |  M 54297883   2840000  0xa2c3927d7aefb869  |  3136K  0.06641   5.3689   53.68s  |  3:04:57:25   5.23%  |
|  Dec 26  22:35:47  |  M 54297883   2850000  0xf5b7f62de86145e4  |  3136K  0.06641   5.3705   53.70s  |  3:04:56:28   5.24%  |
C:/CUDA/CuLu/src/CUDALucas.cu(1509) : cudaSafeCall() Runtime API error 6: the launch timed out and was terminated.
Resetting device and restarting from last checkpoint.
 Using threads: norm1 256, mult 256, norm2 1024.
C:/CUDA/CuLu/src/CUDALucas.cu(891) : cudaSafeCall() Runtime API error 46: all CUDA-capable devices are busy or unavailable.

[frmky]

In 64-bit Linux, r56 segfaults when I run with -r, but has correctly completed a number of double-checks. r59 simply exits without starting a test from worktodo.txt.

[owftheevil]

Does r59 work ok with -r?

Edit: For the exiting without starting a test in r59, on line 3346 in CUDALucas.cu, take the negation off of get_next_assignment. That should do it, although I can't check it myself right now.

[frmky]

No, r59 crashes as well.

Program received signal SIGSEGV, Segmentation fault.
0x000000000040420f in init_lucas (x_packed=0x6ddba0, q=86243, 
    n=0x7fffffffe044, j=0x7fffffffe040, offset=0x7fffffffe03c, total_time=0x0, 
    time_adj=0x0, iter_adj=0x0) at CUDALucas.cu:1317
1317        *time_adj = *total_time;
(gdb) bt
#0  0x000000000040420f in init_lucas (x_packed=0x6ddba0, q=86243, 
    n=0x7fffffffe044, j=0x7fffffffe040, offset=0x7fffffffe03c, total_time=0x0, 
    time_adj=0x0, iter_adj=0x0) at CUDALucas.cu:1317
#1  0x000000000040bb65 in check_residue (ls=0) at CUDALucas.cu:2624
#2  0x000000000040df57 in main (argc=2, argv=0x7fffffffe1f8)
    at CUDALucas.cu:3334
(gdb) print total_time
$1 = (unsigned long long *) 0x0
(gdb) print time_adj
$2 = (unsigned long long *) 0x0

So time_adj is a null pointer.

[owftheevil]

Thanks frmky, your information was very useful. r60 should fix these bugs.

[flashjh]

r60 compiled and tested (still needs more). CUDA 4.2 up to 5.5 all working, release and debug. All posted to SourceForge

This version (and r57 and up) include new rcb code from Prime95 that give about a 1% speed improvement! Exciting for CUDALucas, but does need testing, please.

In my testing CUDA 5.5 and Win32 are slightly faster than earlier versions or x64 (but you may need a batch file to keep it going, see below)

What works:
-cufftbench
-r
-normal testing

What Doesn't:
-threadbench

Didn't test:
-memtest

For those experiencing stops: This is an nVidia driver issue. Here is some info and I included some workarounds

<=306.97 work with x86/x64 CUDA 4.2 and CUDA 5.0 builds perfectly fine and produces no restarts (at least none from my testing over several days).

>=310.70 have resets no matter what platform/CUDA version including 5.5 with >=320.18.

There are two workarounds for anyone experiencing a similar problem described by mognuts:

1) The best way to fix the error is to downgrade your driver to one of the versions <=306.97 as mentioned above.

CUDA Driver Versions:

CUDA 5.5:                  CUDA 5.0                 CUDA 4.2
331.82  19-Nov-13          314.22   25-Mar-13       301.42  22-May-12
331.65  07-Nov-13          314.07   18-Feb-13       296.10  13-Mar-12
331.58  21-Oct-13          310.90   05-Jan-13       295.73  21-Feb-12
327.23  19-Sep-13          310.70   17-Dec-12       285.62  24-Oct-11
320.49  01-Jul-13          306.97   10-Oct-12       280.26  09-Aug-11
320.18  23-May-13          306.23   13-Sep-12       275.33  01-Jun-11

I did not actually test below 296.10 so I don't know where the CUDA changes over to < CUDA 4.2 but I figure most will be on 296.10 by now.

Windows CUDALucas from CUDA 4.0 up to 5.5, 32 or 64 bit are on SourceForge

Request: I need to know who else is having the *stop* issue and what driver and video card you have. I'm working with NVidia to try and get the drivers fixed, so it will be helpful to know what other cards have this issue.

2) The other 'fix' for this issue is to use a batch file similar to this:

@echo off
Set count=0
Set program=CUDALucas2.05Beta-CUDA5.0-Win32-r60
:loop
TITLE %program% Current Reset Count = %count%
Set /A count+=1
rem echo %count% >> log.txt
rem echo %count%
%program%.exe
GOTO loop

This will restart CUDALucas each time it stops and allow you see how many resets have occurred, if you care.

I have not been able to thoroughly test speeds yet; I know that CUDA 5.5 is usually faster, but at the cost of having the driver lockup. Combined with the batch file, there really is no issue other than if the restarts bother you as I've run many good DCs with the batch file.

With <=306.97, you don't need the batch file and there are no restarts, but it could potentially be &slightly* slower. I would love to see actual test data from everyone. Also, if anyone does experience the *stop* while on <=306.97, please let me know ASAP so I can update this info and nVidia.

As for reliability, I have completed many successful tests with 2.05 Beta, CUDA 4.0 up to 5.5, 32 and 64 bit. Many with a lot of stop and restarts and forced FFT size changes for testing the code.

[flashjh]

r62 posted to fix the -threadbench problem

Usage for testing:

CUDALucas -cufftbench lb ub p (e.g. CUDALucas -cufftbench 1 8192 6)

It gives a warning if either lb or ub is not a power of two. It works when they are not, but non optimal lengths near the edges of the range are likely to be included in <gpu> fft.txt.

CUDALucas -threadbench lb ub p m (e.g. CUDALucas -threadbench 1 8192 6 1)

The new parameter m (usually 0 or 1) controls a little bit of the behavior of the test. m = 0 causes all reasonable fft lengths ( n a multiple of 1K, largest prime factor of n is 7) between lb * 1k and ub * 1k to be tested, m = 1 tests only the lengths in <gpu> fft.txt and the table in init_ffts.

When testing the new versions run:

CUDALucas -r
CUDALucas -cufftbench 1 8192 6
CUDALucas -threadbench 1 8192 6 1

You can also run a memtest:

CUDALucas -memtest k n
where k * 25 MB of memory are tested, n * 10000 iterations are done for each of 5 data types at each of the k positions

[blip]

I got the following output:

-- polite interval increased to 2
-- error_reset increased to 95

What does that mean?

[flashjh]

Can you post your Cudalucas.ini and the command line you're using to run the program?

[blip]

I am running it as

CUDALucas -d 0