I'm relatively certain that the problem with your 570 is different from the titan problem. With the titan, the symptoms were almost the same as the other cards--mismatching residues or occasional roundoff errors. On all cards, reducing the memory clock eliminated the problem. But, unlike the other cards, titans didn't show any errors with the memory test program I wrote. Karl M Johnson reported this some time ago, and I found it to be true for my titan also.

On the other hand, it doesn't take much effort to test it out.

[QUOTE]On the other hand, it doesn't take much effort to test it out. [/QUOTE]
True, and I shall!
I'm still pretty much convinced that the VRAM specified for most Geforce cards is fine for game-pixel-pushing at stock speed, but overclocked for more precise use.

[QUOTE=kladner;350183]True, and I shall!
I'm still pretty much convinced that the VRAM specified for most Geforce cards is fine for game-pixel-pushing at stock speed, but overclocked for more precise use.[/QUOTE]

I agree.

Successful run on the first known-factor example in readme.

M50001781 has a factor: 4392938042637898431087689 (P-1, B1=94709, B2=4067587, e=2, n=2688K CUDAPm1 v0.10)

IIRC, it took a total of just over 30 minutes.

I still have to test the 570 card. This was on an Asus 580 that I picked up on impulse from eBay. It was sitting at $150 with no bids. I got it for a total of $169, with shipping.

I knew that the Asus Direct CU cards are big, but you really don't fully get that until you have one in your hands and have to fit it into the case. I had to move a hard drive to a different slot, and it was still a very close thing just maneuvering it in.

EDIT: Program created a "savefiles" folder, but never put anything in it. All the error checking and the "save all" options were turned on in the ini.

Good deal on the 580.

I have the savefiles part commented out at the moment, so thats why nothing got put there.

By the way, don't use that version for production work. There is a bug in stage 2 initialization. It won't find any factors in the first pass. I have the fix committed, but windows and ubuntu are not playing well together at the moment, and I can't build anything new on windows until tomorrow (incredibly slow internet).

[QUOTE=owftheevil;350253]Good deal on the 580.

I have the savefiles part commented out at the moment, so thats why nothing got put there.

By the way, don't use that version for production work. There is a bug in stage 2 initialization. It won't find any factors in the first pass. I have the fix committed, but windows and ubuntu are not playing well together at the moment, and I can't build anything new on windows until tomorrow (incredibly slow internet).[/QUOTE]

Thanks for the info and the caution. So far, I've just been figuring out how to do stuff, and testing the hardware. Having the Known Factor samples in the Readme is a big help.

[QUOTE=owftheevil;350253]
By the way, don't use that version for production work. There is a bug in stage 2 initialization. It won't find any factors in the first pass. I have the fix committed, but windows and ubuntu are not playing well together at the moment, and I can't build anything new on windows until tomorrow (incredibly slow internet).[/QUOTE]

I just got a segfault with the latest SVN. I'm rerunning it from the beginning to verify reproducibility.

[CODE]M62677721, 0x5861c3dd30a23133, n = 3584K, CUDAPm1 v0.10
Stage 1 complete, estimated total time = 59:58
Starting stage 1 gcd.
M62677721 Stage 1 found no factor (P-1, B1=620000, B2=16275000, e=0, n=3584K CUDAPm1 v0.10)
Starting stage 2.
Using b1 = 620000, b2 = 16275000, d = 2310, e = 6, nrp = 160
Zeros: 731774, Ones: 829666, Pairs: 167476
Processing 1 - 160 of 480 relative primes.
nrp = 160, m = 0, d = 2310, e = 6, num_tran = 0, k = 541.
Inititalizing pass... *** glibc detected *** ./CUDAPm1: corrupted double-linked list: 0x0000000004f41cc0 ***
[/CODE]

Submitted a fix. Thanks for finding that.

Ran[CODE]cudapm1-5.0 [U]61012769[/U] -b1 10273 -b2 1572097 -f 3360K[/CODE]in right at 15 min., 2.8493 ms/tran, Stage 2
[CODE]M61012769 has a factor: 2018028590362685212673 (P-1, B1=10273, B2=1572097, e=2, n=3360K CUDAPm1 v0.10)[/CODE]As noted by others, I think, GCD, at least for Stage 2, uses no GPU. In my case it uses the equivalent of one core, (12 %) CPU.

I'm just getting used to behavior, and watching for errors.

nice, now we only have to decide about the version number, if it is 5.0 as the command line says, or 0.10 as the result line says... :razz:

[QUOTE=LaurV;350307]if it is 5.0 as the command line says[/QUOTE]I believe that would be the CUDA version compiled for, not the program version.