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

[kladner]

Originally Posted by flashjh

That's why I was asking about the correct format. I don't want to change the result line, but I can update CUDALucas to output the correct format.

I only have results from 2.04 beta. Not sure if these are helpful.

GTX 460 Match
M( 29862949 )C, 0x0f45a041ecb72f25, n = 1600K, CUDALucas v2.04 Beta, AID: 2D10C4DC57AA33BE93C85980189E980A

GTX 570 Match! 810/1600 MHz
M( 30147757 )C, 0x7f9545e16b069466, n = 1600K, CUDALucas v2.04 Beta, AID: 5F99F53583D4C3E63D3B644739AB6C37

GTX 570SO Match! 810/1600 MHz
M( 28581239 )C, 0xfa28ab555b8bceea, n = 1568K, CUDALucas v2.04 Beta, AID: C278B9C208B1E929C04BCB7EC5DCD91A

GTX 580 Match! 830/1800 Mhz
M( 29691247 )C, 0xd1f3b18c4ba2384c, n = 1728K, CUDALucas v2.04 Beta, AID: AD65555AAC5AF9E5B7128182CF7158F8

GTX 580 Match! 830/2004 Mhz
M( 30078823 )C, 0xc26f399dad087941, n = 1600K, CUDALucas v2.04 Beta, AID: 6BEFF1DF745E6BF8AE8350760B042A78

[flashjh]

Yes, I'll need to talk with James to have the PHP code updated to recognize the 2.05 format.

If anyone sees any changes that need to be made to the result output of 2.05, let us know now so changes are made before James updates the code (hopefully)

[James Heinrich]

Originally Posted by flashjh

Yes, I'll need to talk with James to have the PHP code updated to recognize the 2.05 format.

Yes, you will.

If you can keep the M( <exponent )C style that would be useful. As in, something like:

M( 10061 )C, 0x56eb9bb91825b188, offset = 4054, n = 1K, CUDALucas v2.05 Beta

Other than that, the only change is the addition of the "offset" parameter? If so I can add support for that relatively easily.

[flashjh]

That's no problem, do you want the rest of the line to stay the same?

Edit: keep the AID at the end, if it is there?

BTW - Thanks!

[James Heinrich]

These lines are now handled by mersenne.ca, and will (soon, hopefully) be handled by near-identical code on mersenne.org when I finish debugging the new manual-results parser there:

M( 10061 )C, 0x56eb9bb91825b188, offset = 9029, n = 1K, CUDALucas v2.05 Beta
M( 216091 )P, offset = 1234, n = 12K, CUDALucas v2.05 Beta

I don't know if offset is relevant or would be printed in case of a prime, but it's handled anyways.

Lines can also be prefixed by userID/compID if known:

UID: flashjh/Server, M( 25928543 )C, 0x24b8387cb9765463, n = 1572864, CUDALucas v1.46

And yes, keep the AID at the end if available. So, with everything in:

UID: flashjh/Server, M( 10061 )C, 0x56eb9bb91825b188, offset = 4054, n = 1K, CUDALucas v2.05 Beta, AID: DD556623539A3B33B816E3C5F77D1D97

[flashjh]

Originally Posted by James Heinrich

<>I don't know if offset is relevant or would be printed in case of a prime, but it's handled anyways.<>

You are correct, this is the line:

M( 57885161 )P, n = 3136K, CUDALucas v2.05 Beta

[kladner]

Last few lines of:

E:\CUDA\2.05-BETA>CudaLucas.exe -memtest 56 1 -d 1

Position 22, Data Type 0, Iteration 1110000, Errors: 0, completed 47.23%, Read 82.60GB/s, Write 27.53GB/s, ETA 18:20)
Position 22, Data Type 1, Iteration 1120000, Errors: 0, completed 47.66%, Read 82.44GB/s, Write 27.48GB/s, ETA 18:11)
Position 22, Data Type 2, Iteration 1130000, Errors: 0, completed 48.09%, Read 82.32GB/s, Write 27.44GB/s, ETA 18:02)
Position 22, Data Type 3, Iteration 1140000, Errors: 0, completed 48.51%, Read 82.41GB/s, Write 27.47GB/s, ETA 17:53)
Position 22, Data Type 4, Iteration 1150000, Errors: 0, completed 48.94%, Read 82.67GB/s, Write 27.56GB/s, ETA 17:44)
Position 23, Data Type 0, Iteration 1160000, Errors: 0, completed 49.36%, Read 82.30GB/s, Write 27.43GB/s, ETA 17:35)
Position 23, Data Type 1, Iteration 1170000, Errors: 0, completed 49.79%, Read 82.50GB/s, Write 27.50GB/s, ETA 17:27)
Position 23, Data Type 2, Iteration 1180000, Errors: 0, completed 50.21%, Read 82.60GB/s, Write 27.53GB/s, ETA 17:18)
Position 23, Data Type 3, Iteration 1190000, Errors: 0, completed 50.64%, Read 82.67GB/s, Write 27.56GB/s, ETA 17:09)
Position 23, Data Type 4, Iteration 1200000, Errors: 0, completed 51.06%, Read 82.28GB/s, Write 27.43GB/s, ETA 17:00)
C:/CUDA/CuLu/src/CUDALucas.cu(1438) : cudaSafeCall() Runtime API error 2: out of memory.

EDIT: The GTX 570 is a secondary GPU which does not drive a display, FWIW.

I am now running

CUDALucas -memtest 35 10 -d 1

4.11% complete, ETA: 04:09.

[kladner]

Originally Posted by kladner

.....

I am now running

CUDALucas -memtest 35 10 -d 1

4.11% complete, ETA: 04:09.

The above completed successfully. GTX 570, 844 core, 1600 VRAM

Attached is the latter part of the run; the buffer for cmd was not large enough.

[flashjh]

Originally Posted by LaurV

They are allowed for ages, since 1.48 (the first stable one), few years ago. <...> Edit: sorry, let me be stupid few minutes each day... No coffee yet, this morning.<...> Beside of "shifts", any reasons to switch?

I read your original post the other day, and came back today since I finally have time, and saw that you edited you post.
I am, indeed, talking about being able to do both tests with CUDALucas. There have been a significant amount of changes besides the shifting. A lot of work was done to eliminate errors from bad FFT selection. Primarily, now, CUDALucas handles FFT errors by reverting to the last save and increasing FFT appropriately. In fact, the original FFT selection is much better too. It makes sense to run the -cufftbench as you discussed to generate a good FFT file for your card. Memtest is also incorporated into this version now.

Edit 2: some simple mechanism to protect against fraud is still missing, I would vote against accepting "first-time LL" and "DC" from cudaLucas, for the same exponent. What stops me to edit the "offset" parameter, to get the credit two times? You will find after 20 years that we missed a prime because some idiot credit-whore (I learned the word here on the forum, as someone called it, sorry). At least, with P95 is not so easy for childish individuals to fake a report, due to the we1 checksum, etc. Some simple security mechanism should be implemented, beside of shifting, to make it safer. Don't get me wrong, no disrespect for your work, shifting is an immense improvement to guard against software (FFT bugs), for which I am very grateful.

I agree, but was falsely under the impression that the shift was what was missing to allow 1st-time and DCs on the same exponent. Your suggestion is heard loud and clear, but we need to know what ideas can be implemented to allow for both checks. Ideas?

Edit 3: (BTW, after updating the drivers, I am also getting negative iteration times and negative ETA's too, which are very accurate if you multiply them with (about) minus 28 (!?!??!), and consider them in minutes, not in hours , using the "old good version" 2.04, untouched since Dubslow made it. But the residues are right, and it is about 1% faster, so I let it be).

If I may, I request that you please download and test 2.05Beta after your next exponent completes (there is a debug version if you need it). -t is always enabled now, but it is quite fast. I compile it with CUDA 5.5 using sm 13,20,30,35. I have actually tried to 'break' it messing with FFT sizes, etc. With rare exception it handles everything I throw at it and despite all my testing the checksums have all matched (so far). I've even had two that matched with two bad checksums (30424021 & 30793229). I also ran M62807803 that Lan_party had trouble with and got a match, though I can't submit the result

If you (or anyone else) start testing, please test the keyboard interaction on Windows as I have been unable to get it to work. If it does work for you then I'll know it's my system.

Originally Posted by James Heinrich

These lines are now handled by mersenne.ca, and will (soon, hopefully) be handled by near-identical code on mersenne.org<>

Originally Posted by Prime95

Can we change the intermediate output (example below) so that it does not look very much like the final result lines?<>

The changes to the output of 2.05Beta are done and I'll upload them shortly. The results file now outputs the format above, but the screen output is simplified for better formatting and to not allow GIMPS to read the result without a lot of changes that someone would need to do on purpose. In the future I'm sure we can implement output formatting similar to mfaktX.

[kladner]

I ran the r47 version (not debug) overnight on both cards: 570 and 580. Event viewer shows two display driver restarts.

>>I experimented last night with the interactive feature. These are some great enhancements! Increase/decrease checkpoint interval works fine, as does +/- FFT. Auto FFT seems to make the best choices, so far. Decreasing always provoked a "restart with larger" response. Increasing several steps gave progressively slower performance. Toggle Polite works, as it always has.<<

I have up to date FFT and Threads files, generated yesterday. Stability seems to have improved, as I got multiple successful -r selftest runs on both cards. -memtest 35 10 completed on the 570. It ran for about two hours on the 580 without errors, but I got impatient and did not let it finish.

Let me know if there is any other info I might be able to provide. The two assignments are still running, so I don't know about residue matches, yet. I have 13 and 17 hours to go on those.

[flashjh]

r48 is up with the updated display and results file output

So the Windows version allows you to use the interactive mode?

Edit: Attached a zip file with a .bat of LaurV's post (corrected)