Just these two (26059867 and the "M48"). I am not interested enough to make it a regular activity, I was only interested to see if this program works. My plan is to run gpuLucas on the same two numbers, but later, because the end result is somewhat underwhelmingly predictable.:smile:

[QUOTE=apsen;292433]Got mismatch for 29027371 with 1.63. :sad:[/QUOTE]
Ver 1.64 have -s and -t option,Please try.
[code]
$ ./CUDALucas
Usage: ./CUDALucas [-d device_number] [-c checkpoint_iteration] [-f fft_length] [-s] [-t] -r|exponent|input_filename
-f set fft length
-s save all checkpoint files
-t check round off error all iterations,when err > 0.49 exit
[/code]

[QUOTE=Batalov;292464]Just these two (26059867 and the "M48"). I am not interested enough to make it a regular activity, I was only interested to see if this program works. My plan is to run gpuLucas on the same two numbers, but later, because the end result is somewhat underwhelmingly predictable.:smile:[/QUOTE]

I look forward to those results, when they happen.

I re-ran a series of DC exponents which gave me bad residues in the past (sorry for poaching, they were already re-assigned). I have another 2 matches (totally 4) using v1.64 with -s and -t. Seems to be stable and "well behaved". I am trying 3 expos in the first-time-LL (45M+) front, I will not report the results before DC-ing them with P95 to make sure. CudaLucas v1.64, ~10 hours to go for the first two.

By the way, I found a small cosmetic bug: when -c/-s/-t switches are paired together with -r, CL will crash. There should be a small description, or different pairing of the square brackets in the command line help, or better an improved implementation of the command line parser...

replying to myself... thats a bit odd.. :D

I was quite optimistic... I just reached home after work (my working Saturday today) and found:

[CODE]>cl1644120w64 -d 0 -c 250000 -s -t 45130601
...<snip>...
Iteration 33750000 M( 45130601 )C, ....
err = 0.499978,round off err exiting.
[/CODE]it seems to be reproducible, and I would try to insulate it, by calling CL with -c 1k (it was called with -c 250k -s -t).

Two observations came out from this:

First, you can see the utility of -t, as I said before, better safe then sorry. The safety highly compensates for slowness, imagine I would have to repeat whole 33M iterations again... Now the only last 250k (max) would need to be repeated, which is in fact A GAIN OF SPEED, despite the 2% penalty. I love -t! :D I would like to have it setable (like 0.45, 0.37, whatever I like, parameter of the -t switch?).

And the second observation: [B]would it be possible to spit out the iteration number and eventually save a checkpoint file with previous residue when this round off error happens[/B]? This would save me from re-running the last 250k (or 500k, or 1M) iterations to insulate the error. I can not use lower values for -c, because the harddisk space will be eaten up very fast by the save files, so 250k is a perfect value for a residue-comparison process, but in case of roundoff error, it would take longer to insulate it or repeat the test.

Regarding what is safe round off error -- when testing which FFT size to use, Prime95 requires that the average round off be less than .24 (roughly), NOT less than .49. Here's what George had to say:
[url]http://www.mersenneforum.org/showpost.php?p=291942&postcount=102[/url]

That would presumably prevent errors like LaurV just encountered.

George reffers to the AVERAGE roundoff error (for 100 or 1k iterations, or so). Which indeed would need to be much lower to catch the spikes going over 0.5. If you check it at every iteration (what -t is doing) then comparing it with 0.5 would be enough. But we skeptic being, to set it lower we would like... (paraphrasing master Yoda..)

[QUOTE=LaurV;292485]By the way, I found a small cosmetic bug: when -c/-s/-t switches are paired together with -r, CL will crash. There should be a small description, or different pairing of the square brackets in the command line help, or better an improved implementation of the command line parser...[/QUOTE]
Please more information.With linux is OK.

The roundoff error have two causes, fft length or HW error.
HW error need down clock.

Perfect, again
 

Still no mismatch here:
[CODE]Processing result: M( 29013107 )C, 0xd9e76769f7b81b52, n = 1572864, CUDALucas v1.64
LL test successfully completes double-check of M29013107[/CODE]

[QUOTE=apsen;292326]Did you get a mismatch? Or is it still running?[/QUOTE]
[code]
M( 29198173 )C, 0x6fd7e4d6557f5b77, n = 1572864, CUDALucas v1.58
[/code]
correct.