[QUOTE=frmky;444252]No, I'm just using an older version that I know is reliable and using a fixed FFT size appropriate for the DC's I had been doing. The range just crept up to the borderline without me noticing it at first.[/QUOTE]

I have noticed something in my rounds of tests. When cudaLucas (and maybe clLucas, since it was a port) start getting higher errors at a small FFT size they back up and repeat the last X iterations with the next largest FFT size. At some point if the errors stay low it returns to the previous smaller FFT size.

Whenever this happens there a roughly 1/5 chance my final result is wrong. I have yet to look for a way to force it to either continue at new larger size, or even restart at the new larger size.

You can specify the FFT for each line in worktodo file. I used to do that in the past due to different (type of) cards having different speeds at the same FFT size, so I used to select the FFT for each exponent per each card. Later versions of cudaLucas came with auto-tuning facilities (which you still [U]have to run![/U] for your card, when you install cudaLucas) and I don't do it anymore, but it is still possible. You also could use the default FFT settings in the ini file.

[QUOTE=LaurV;444292]Later versions of cudaLucas came with auto-tuning facilities (which you still [U]have to run![/U] for your card, when you install cudaLucas) and I don't do it anymore, but it is still possible. You also could use the default FFT settings in the ini file.[/QUOTE]

But there are no FFT settings in the CUDALucas.ini file, other than an obsolete FFTLength parameter which applies to all exponents if it is set.

From the documentation, running with the -cufftbench option writes a file <gpu> fft.txt with parameters for FFT length selection. However, this file is not read by the CUDALucas program. It seems to be for information only, for human visual inspection.

If you don't want to rely on automatic selection of FFT lengths, you have manually specify the FFT length for each exponent (as a command line option, or in the worktodo.txt line the same way that mprime does it). There seems to be no way to add the fft.txt information to CUDALucas.ini, to change the way the program automatically selects FFT lengths.

In my experience if you have run the -cufftbench and it created a <GPU> fft.txt you can rely on the auto select if it is far from a "border" exponent, but these limits are set rather high, so near the "borders" I manually choose the higher one.

For example:
2048 38492887 1.2845
2592 48471289 1.6135
2744 51250889 2.0056
3136 58404433 2.0937
3200 59570449 2.4195
4000 74106457 2.4631
4096 75846319 2.5115
4320 79902611 3.2614

if I had an exponent above 48.2M or even 48M I would use 2744K instead of 2592K, even if it says the border is 48.47M

[QUOTE=ATH;444315]...if I had an exponent above 48.2M or even 48M I would use 2744K instead of 2592K, even if it says the border is 48.47M[/QUOTE]

Prime95 has the concept already of doing a test around certain FFT boundaries to see if the lower size is safe or not. I wonder if that could be adapted for GPU? It sounds like it could be important.

I could probably lower all the boundaries manually with 200k in the .txt file, I just haven't tried it yet.

[QUOTE=ATH;444406]I could probably lower all the boundaries manually with 200k in the .txt file, I just haven't tried it yet.[/QUOTE]

Do you (or anyone else) know the [B]exact[/B] exponent sizes that cudalucas uses for it's FFT breakpoints?

Firstly, that would help me better pick optimal exponents for AirSquirrels... I'm using the default thresholds from Prime95 although now I don't remember if I picked them from the SSE or AVX settings.

Secondly, if this is really an area of concern, where exponents near the upper end of an FFT range can experience issues, maybe that's something to scan for in the history (results turned in by cudalucas near the boundaries, and their general error rate). It could be predictive in helping find unknown bad results.

In AirSquirrel's case, the results I've triple-checked from him where his ended up being bad had the dubious distinction of not having any error code set. Does cudalucas not generally track that kind of thing? Prime95 will track things like rolling back and retrying with a larger FFT, even if it's reproducible. I just wonder if there's a way I can look at unknown cudalucas results and tell if they had any rollbacks or not.

Incidentally, in his particular case, he's noticed that his AMD cards do HORRIBLE at certain FFT sizes. Like, really really bad. So bad, it seemed to me like it could run a test faster by going to a larger FFT size. Is that a known issue?

One other "complaint" about cudalucas is the lack of a shift count feature... fortunately it doesn't happen much, but 2 or 3 times I've accidentally assigned work to him that was done on cudalucas and was also previously done by cudalucas... so both runs had a zero shift count. Whoops. I've done my own triple-check on those. It would sure be nice if it could do that just like other software, but it's not a huge deal. I just have to remember to exclude anything where either of the two possible mismatching results has a shift count of zero.

[QUOTE=Madpoo;444466]One other "complaint" about cudalucas is the lack of a shift count feature... fortunately it doesn't happen much, but 2 or 3 times I've accidentally assigned work to him that was done on cudalucas and was also previously done by cudalucas... so both runs had a zero shift count.[/QUOTE]

I think it did get a shift count some time ago.

The results.txt lines include an "offset = " clause which looks very much like a shift count. The value is invariably between 0 and p.

Example:
[CODE]M( [URL="http://www.mersenne.org/report_exponent/?exp_lo=39529741&full=1"]39529741[/URL] )C, 0xb12e6cd5d623ddc5, offset = 11620785, n = 2160K, CUDALucas v2.05.1[/CODE]

Is this value not being recorded when results are reported manually?

[QUOTE=GP2;444297]From the documentation, running with the -cufftbench option writes a file <gpu> fft.txt with parameters for FFT length selection. However, this file is not read by the CUDALucas program. It seems to be for information only, for human visual inspection.[/QUOTE]

From looking at the source code, the program actually does read in the <gpu> fft.txt file. The documentation does not mention this, it only describes the option to create this file.

[QUOTE=Madpoo;444466]Do you (or anyone else) know the [B]exact[/B] exponent sizes that cudalucas uses for it's FFT breakpoints?[/QUOTE]

Here is a list up to 8192K, let me know if you need higher (the FFT is in kilobyte):
[url]http://hoegge.dk/mersenne/CUDALucasFFTranges.txt[/url]

The FFT ranges are produced on a per card basis. What card was that file produced with, ATH?

Yes, the tests are shifted per GP2's comments.