[QUOTE=TObject;427311]

[b]Display driver nvlddmkm stopped responding and has successfully recovered.[/b]

[/QUOTE]

That usually means that the GPU is not stable, noticed some serious miscalculation and resets itself. I would not trust the running test to be valid anymore.

I got a similar message on a laptop, where the graphics card was dying.

I do not think the consumer versions of GPU have any kind of error detection. This feels more like sloppy driver/driver infrastructure on Nvidia or Microsoft part.

This could, of course, be exacerbated by a failing GPU…

I think, if you look back to this thread, you will find discussion of this issue. I believe that the expert opinion is that this problem started with a particular (OLD!) driver version. Some people have created .bat files which will loop and restart CuLu. This does not seem to correlate with bad results.

If the card can pass the long self-test (-r 1), it is a fairly good indication of stability. If you get anything but correct results in this test, try dropping your memory speed in 100 MHz increments.

CUDALucas seems to be ignoring the fft file created during benchmarks (though it does appear to follow the threads file).

Is the fft benchmark strictly for my information, and I need to plug the fft size manually?

Thanks.

[QUOTE=TObject;427345]CUDALucas seems to be ignoring the fft file created during benchmarks (though it does appear to follow the threads file).

Is the fft benchmark strictly for my information, and I need to plug the fft size manually?

Thanks.[/QUOTE]
On my system, it seems that CuLu generally runs at one step higher FFT than P95 would for exponents in the same range.

FWIW, I let the test run for three million iterations with 18432K FFT. I then restarted from the begging with 19208K FFT (no round off errors this time).

Both runs produced matching residues.

[QUOTE=TObject;427304]I keep getting the round off >0.35 errors once every 100K-200k iterations on a hundred million digit test I just started (a 332M exponent).

Before starting the test I run both FFT and threads benchmarks from 1024K to 32768K FFT lengths.

Device: GeForce GTX TITAN
CUDALucas2.05.1-CUDA6.5-Windows-WIN32

The parameters CUDALucas picked for this test are:
18432K FFT
512 Threads
32 Splices

The BigCarry parameter is 0.

What would you recommend I do for this test? Restart it with a larger FFT size?

The Titan passed tests and did a few matching double-checks beforehand.

Thanks.[/QUOTE]

My FFT.txt file says:
[CODE] fft max exp ms/iter
18144 325388893 13.6501
18432 330441847 14.0534
19208 344048303 14.1962
19600 350917159 14.5269[/CODE]

So 18432 K FFT should be too small for a 100M digit exponent (~332.2M+)


But it does not always stick to those limits it seems because when I double checked M36670561 it chose 1944K FFT even though it should have chosen 2000K according to the fft file:

[CODE] fft max exp ms/iter
1728 32597297 1.1656
1944 36579149 1.2477
2000 37609879 1.2572
2048 38492887 1.3148[/CODE]

Also it does not choose those limits very aggressively. When I tested M36532913 in the 1944K range I got errors up to 0.32031 which should be ok I guess but which I do not like. So now I normally choose FFT manually if the exponent is close to a border.

Agh... 2 more false positives came in today from:
"CUDALucas v2.05.1"

The results were reported in *manually* just an hour or so after they were assigned.

So... first thing, if you just started work on an exponent and you miraculously found a prime within an hour of starting, don't submit it as a new prime, double-check your setup.

Second thing, what bug in CUDALucas v2.05.1 is doing this? That makes something like 4 or 5 of them in a couple month's time.

Its most likley a mismatch between the compute capability of the card and what the binary generates. I don't have much time to fiddle with it now, but I'll try to get something worked out by this weekend.

[QUOTE=Madpoo;427955]Agh... 2 more false positives came in today from:
"CUDALucas v2.05.1"

Second thing, what bug in CUDALucas v2.05.1 is doing this? That makes something like 4 or 5 of them in a couple month's time.[/QUOTE]

My cudaLucas was finding primes when every iteration printed a 0 residue.
Recompiling with compute capability 2.0 fixed it for me.

Later a Ubuntu update installed a new nvidia driver and the 0 residue's returned.
Another recompile fixed it.

The cudaLucas author posted a code change to check for residue 0 and
asked for comments on the code change. The last update on sourceforge
was 2015-02-27.

The llloop.py script from primetools uses the manual results page so it may
not have been a person submitting it.

Correction made. It now aborts the test when a premature 0 residue occurs. It wil take a few days to get sourceforge updated. (Extemely unreliable and slow internet connection.)