[QUOTE=Stef42;339559]I've got this exponent until iteration 50.000 run for you.
[URL]https://dl.dropboxusercontent.com/u/27359940/CUDAPm1%2050000.txt[/URL][/QUOTE]

I'm sorry, but my memory was wrong. It was iteration 450000 where the residues began to diverge. Yours match both of ours up to 50000. The reason thats important is that I'm at work now and have no access to my results, but I do have access to his. Thanks for the input.

[QUOTE=owftheevil;339562]I'm sorry, but my memory was wrong. It was iteration 450000 where the residues began to diverge. Yours match both of ours up to 50000. The reason thats important is that I'm at work now and have no access to my results, but I do have access to his. Thanks for the input.[/QUOTE]

Then I'll see if I can get it up to 450000 in a few hours...

[QUOTE=owftheevil;339561]As to the cudaDevice Synchronize errors people are seeing, I'm almost convinced it is an Nvidia driver bug. On Linux, I'm getting something similar, only its a timeout error (error 6) instead of an unidentified error.[/QUOTE]

I thought the fact that it only happened (for me at least) when the cpu was occupied was important, considering Chasall's problems cropping up only when the cpu was running as well. Also if the purpose of the call directly related to the cpu (I believe it was described as keeping the cpu from running a loop while waiting?) the inverse situation where the cpu was already too busy to run a wait loop anyway might be relevant. The 580 is my main display card though - I'll try running the program on the 480 and see what it does. It has 1.5 gb of memory, which should be enough I hope.

EDIT: The quote I was trying to remember:
[QUOTE=owftheevil;339389]The different kernels run synchronously, the cutilSafeThreadSync call is so the cpu doesn't do busy waiting and eat up an entire cpu core.[/QUOTE] I had the wrong function call in mind.

My run found the factor:

[CODE]Iteration 764000 M61394569, 0xa524c6ae8ad4a231, n = 3360K, CUDAPm1 v0.10 err = 0.21777 (0:07 real, 6.9230 ms/iter, ETA 0:06)
M61394569, 0x30c664a860055a8f, n = 3360K, CUDAPm1 v0.10
Stage 1 complete, estimated total time = 1:28:32
.
.
.
Accumulated Product: M61394569, 0x80e4aa01c3bb4d17, n = 3360K, CUDAPm1 v0.10
Starting stage 2 gcd.
M61394569 has a factor: 189843460261039170580823 (P-1, B1=530000, B2=12985000, e=6, n=3360K CUDAPm1 v0.10)
[/CODE]@ Aramis Wyler: I think the error coming at high cpu load and not at low cpu load is coincidence, although I'm not ruling anything out yet. That's the reason I want to do some runs with the explicit and implicit host synchronizations removed.

Here's a couple more that can be used for testing. I found these overnight.

[CODE]M61747963 has a factor: 13383883517343994527281 (P-1, B1=610000, B2=610000, e=6, n=3584K CUDAPm1 v0.10)
M61829329 has a factor: 894781313041001886421561 (P-1, B1=615000, B2=16912500, e=6, n=3584K CUDAPm1 v0.10)
[/CODE]

The first can be found in stage 1 with B1 = 3750. The second can be found with B1 = 750, B2 = 2750000.

[QUOTE=owftheevil;339595]@ Aramis Wyler: I think the error coming at high cpu load and not at low cpu load is coincidence, although I'm not ruling anything out yet. That's the reason I want to do some runs with the explicit and implicit host synchronizations removed.[/QUOTE]

Indeed. My card appears to be the worst possible case for debugging -- it seems to be [B][I][U]just[/U][/I][/B] unstable.

I have spent days running tests in different situations -- heavy CPU load, no CPU load. Low ambient temperatures, high ambient temperatures. Low vRAM usage, high vRAM usage. And all the various combinations of the above.

I can find no correlation to the errors.

While it's still possible that there is a software bug somewhere in the stack, the evidence seems to suggest I have a bad card.

[QUOTE=frmky;339214]New versions ...
Win32:
[URL]https://www.dropbox.com/s/alz4xodjjend7bi/cudapm1_win32_20130503.zip[/URL]
As usual, please let me know of problems.[/QUOTE]

So, what exactly do I have to do after downloading? The .exe doesn't seem to work as-is for me...

I ran the same worktodo as before on my secondary card (a 480) to avoid the conditions mentioned earlier (used for display, etc). It didn't find a factor for M61262347, B1 = 605000, B2 = 16637500, e = 6, fft length = 3360K. It crashed trying to do M61394569, B1 = 605000, B2 = 16637500, e = 6, fft length = 3360K, but even more unforunate for me is that it used different bounds than my 580 did so the residues are completely different. I'll have to try to run it again and specify the bounds. The error on crash:

Iteration 587000 M61394569, 0x689e7131d4d15b81, n = 3360K, CUDAPm1 v0.10 err = 0.20313 (0:07 real, 6.7823 ms/iter, ETA 32:20)
Iteration = 587400, err = 0.46094 >= 0.43, quitting.
Estimated time spent so far: 1:06:31
C:/Users/childers/Dropbox/NFS/cudapm1/build/cudapm1-code-21/cudapm1-code-21/trunk/CUDAPm1.cu(1362) : cudaSafeCall() Runtime API error 17: invalid device pointer.

Though it looks to me like it didn't really crash, it quit because of a rounding error... and possibly then crashed. Full output is [URL="http://workforce.calu.edu/staffen/cudapm1-480.txt"]here[/URL].

Yeah, if it quits during stage 1, I still have it trying to free stage 2 device memory, which hasn't been allocated yet. Fix coming soon.

[QUOTE=c10ck3r;339620]So, what exactly do I have to do after downloading? The .exe doesn't seem to work as-is for me...[/QUOTE]

BUMP
U
M
P
!?!?!
Thanks!

1. Goto [url=http://www.mersenne.org/manual_assignment/] this page.
2. Select P-1 factoring.
3. Put whatever the server gives you into the worktodo.txt file, which is located in CUDAPm1's folder.
4. Create a batch file, say, run.bat, right click on it and select edit.
5. Paste the following there:
[CODE]CUDAPm1
pause[/CODE]
6. Save it, open CUDAPm1.ini, tweak your settings, save em.
7. Run the batch file. It will process one assignment at a time from the worktodo.txt file.