[QUOTE=paulunderwood;552715]It looks like the cofactor is given: 765044109502655639249[/QUOTE]

I reserved two more to actually run. "First PRP tests on Mersenne cofactors." I remember factors being in quotes for ECM's. I had an idea that the number above was similar in purpose.

[QUOTE=Google]A [B]Cofactor[/B], in [B]mathematics[/B], is used to find the inverse of the matrix, adjoined. The [B]Cofactor[/B] is the number you get when you remove the column and row of a designated element in a matrix, which is just a numerical grid in the form of rectangle or a square.[/QUOTE]

Alright, I will take their word for it. :smile:

15 = 5 * 3
5 = factor
3 = cofactor

1260 = 7 * 5 * 36
7 = prime factor
5 = prime factor
36 = composite cofactor (will not be a PRP prime.)

[url]https://www.thefreedictionary.com/cofactor[/url]

"1. One of two or more contributing factors."

:grin:

[QUOTE=storm5510;552712]The worktodo line said "PRP" only. The result line says "PRP-3." Below is a test I pulled from Primenet for demonstration only. I unreserved it later.

[CODE]PRP=xxxx,1,2,10369241,-1,99,0,"765044109502655639249"[/CODE]The assignment in my account also reads "PRP." The reservation was from "Double-check tests on Mersenne cofactors." I do not know how a determination is made based on the work line as to the type.[/QUOTE]

It seems GpuOwl accepts the PRP line with the cofactor present, but GpuOwl not being aware of or using the cofactor in any way may be sub-optimal. GpuOwl will simply run a classic PRP test, which guess what will turn out "not prime", but that was already known at the start.

MPrime OTH may make some use of the cofactor by running a PRP-CF test.

(best use GpuOwl for "first time PRP" or similar)

[QUOTE=preda;552747]It seems GpuOwl accepts the PRP line with the cofactor present, but GpuOwl not being aware of or using the cofactor in any way may be sub-optimal...
[/QUOTE]

In simpler terms, the cofactor is ignored.

[QUOTE=Uncwillly]5 = 5 * 3
5 = factor
3 = cofactor

1260 = 7 * 5 * 36
7 = prime factor
5 = prime factor
36 = composite cofactor (will not be a PRP prime.) [/QUOTE]

Leave it to [U]Google[/U] to complicate something simple.

[QUOTE=preda;552747]It seems GpuOwl accepts the PRP line with the cofactor present, but GpuOwl not being aware of or using the cofactor in any way may be sub-optimal. GpuOwl will simply run a classic PRP test, which guess what will turn out "not prime", but that was already known at the start.

MPrime OTH may make some use of the cofactor by running a PRP-CF test.

(best use GpuOwl for "first time PRP" or similar)[/QUOTE]

Basically that prp-cf test it the same as the prp test, just in the end there is a big division.
Even if the server already accepted such runs from your gpuowl (is it/was it possible?), then it is still not a mistake, if we stored the res2048 residue, see: [url]https://www.mersenneforum.org/showthread.php?t=23462[/url] . As if d=1 then prp=prp cf.

Changing test types for just a minute. I ran this:

[QUOTE]PFactor=xxxx,1,2,99771479,-1,77,2

[/QUOTE]The bounds, 600,000 and 30,000,000 respectively. Suggested by [B][I]preda[/I][/B], I reduced the B1 and left B2 at it default. Below was the result of trying to begin Stage 2:

[QUOTE]Exception gpu_error: MEM_OBJECT_ALLOCATION_FAILURE clEnqueueCopyBuffer(queue.src, dst, 0, 0, size, 0, NULL, NULL) at clwrap.cpp:339 copybuf[/QUOTE]I found the issue, [I]maxAlloc[/I]. I had it too high, 7,000. I dropped it to 6,000 and it went on the Stage 2. Caveat: For a B2 of this size, at least 12 hours, perhaps more.

Some Nvidia GPU's are better suited for running specific tasks, while different models may be better with others. Mine, it has something to do with integer math, or type of integer math. It is great at running TF. Anything else, not so much.

When I got up this morning, I found [I]gpuOwl[/I] has stopped running during the early AM. There was no visual indication on the screen, but my widget showed the GPU as being at idle temperature. The GPU's RAM was still allocated. I looked at the system logs. There was nothing relative at the time it stopped.

I attempted a stop by using Ctrl-C. [I]gpuOwl[/I] appeared to resume running as it displayed another output line on the screen and the GPU began to heat up. A second Ctrl-C stopped it properly. I restarted it and finished the test.

The stoppage happened most of the way through Stage 2 of a P-1 test. Below are some particulars:

[QUOTE]M99785863 (Completed and submitted)
B1 = 600,000
B2 = 20,000,000
maxAlloc 6,000 of a possible 8,000
[I]gpuOwl[/I] version 6.11-364-g36f4e2a
Windows 10 Pro x64 v1909
Command Prompt console, (not PowerShell).[/QUOTE]One thing prior to this yesterday evening was a requested restart by Window 10 to apply update(s). There were no problems.

I restarted again as I have two additional assignments very close in size to the one where the stoppage occurred. I changed no parameters. I want to see if there will be a repeat of the problem.

379 & 3.7.0
 

I have just upgraded to the latest commit and Rocm 3.7.0 and am seeing a ~0.5% speed up.

[QUOTE=paulunderwood;554471]I have just upgraded to the latest commit and Rocm 3.7.0 and am seeing a ~0.5% speed up.[/QUOTE]

Upgraded from which ROCm? 2.2 or 2.3?

[QUOTE=preda;554477]Upgraded from which ROCm? 2.2 or 2.3?[/QUOTE]
Rocm 3.5.1. I have to hack the Makefile, now to Rocm 3.7.0.