[QUOTE=preda;513057]With its 16GB of RAM, R7 is also quite good at P-1.
I'm doing P-1(B1=300K,B2=9M) on 91M exponents in about 17min/test.
(and I found this 118-bit factor: 420168247365933163207630527781851871 )[/QUOTE]


I noted that the Radeon VII utilization rate never crosses 75% even for a large number like a 332M.

[QUOTE=preda;513062]Yes, assignments like
PFactor=AID,1,2,91157513,-1,77,2

these are easily generated/submitted by e.g.:
gpuowl/primenet.py -u user -p passwd --dirs workdir -w PM1 --tasks 40

and for B1/B2 I add to openowl e.g.:
./openowl -B1 300000
./openowl -B1 1000000 -rB2 25

Bounds (B1,B2) can also be specified per-exponent, by prefixing the worktodo line with:
B1=x;line
B1=x,B2=y;line[/QUOTE]

There's a minor bug when finishing a P-1 job as the last in the worktodo file, it doesn't generate a result. Probably introduced by the latest commit to overlap the start and end of tests, openowl quits before generating the result. Normally primenet would keep the worktodo filled and the problem isn't encountered. Also there looks to be a minor off-by-one bug with the stage 2 round naming. Admittedly it is quite amusing to see it nearly finish crunching, say bye then just bugger off:
[code]2019-04-08 18:40:30 Round 35 of 36: init 2.25 s; 5.59 ms/mul; 21285 muls
2019-04-08 18:40:30 Bye[/code][QUOTE=SELROC;513099]I noted that the Radeon VII utilization rate never crosses 75% even for a large number like a 332M.[/QUOTE]
The utilisation granularity at least in rocm-smi is 25%, when testing TF performance it kept bouncing between 50 and 75 with nothing in between. I wouldn't trust it, 99% utilisation could show as 75% depending on how they implemented it.

[QUOTE=M344587487;513131]There's a minor bug when finishing a P-1 job as the last in the worktodo file, it doesn't generate a result. Probably introduced by the latest commit to overlap the start and end of tests, openowl quits before generating the result. Normally primenet would keep the worktodo filled and the problem isn't encountered. Also there looks to be a minor off-by-one bug with the stage 2 round naming. Admittedly it is quite amusing to see it nearly finish crunching, say bye then just bugger off:
[code]2019-04-08 18:40:30 Round 35 of 36: init 2.25 s; 5.59 ms/mul; 21285 muls
2019-04-08 18:40:30 Bye[/code]The utilisation granularity at least in rocm-smi is 25%, when testing TF performance it kept bouncing between 50 and 75 with nothing in between. I wouldn't trust it, 99% utilisation could show as 75% depending on how they implemented it.[/QUOTE]


you are right, I should try with amdcovc, another gpu monitor program.

[QUOTE=M344587487;513131]There's a minor bug when finishing a P-1 job as the last in the worktodo file, it doesn't generate a result. Probably introduced by the latest commit to overlap the start and end of tests, openowl quits before generating the result. Normally primenet would keep the worktodo filled and the problem isn't encountered. Also there looks to be a minor off-by-one bug with the stage 2 round naming. Admittedly it is quite amusing to see it nearly finish crunching, say bye then just bugger off:
[code]2019-04-08 18:40:30 Round 35 of 36: init 2.25 s; 5.59 ms/mul; 21285 muls
2019-04-08 18:40:30 Bye[/code]
[/QUOTE]

Yes I'm aware of this bug. I did introduce it in the last commit, where the final stage-2 GCD is done in the background (i.e. overlapped with the next test), which is a useful optimization for quick P-1 tests; but yep the bug is annoying, I'll think about a fix.

[QUOTE=kriesel;513075]For such an exponent, B1=300K, or B2=9M, look low to me.
See for example [URL]https://www.mersenne.org/report_exponent/?exp_lo=91140901&full=1[/URL]
B1= 745 000
B2= 17 135 000
run in CUDAPm1 v0.20 on a GTX1070 (8GB)

Or [M]M90888739[/M], B1=870000, B2=18052500, e=12, in CUDAPm1 v0.22 on a GTX1080Ti (11GB)[/QUOTE]

The theoretical probability of finding a factor (according to mersenne.ca) with those bounds is 2.16%, empirically I see 3/110. At this rate, and time per test, it is worth doing the P-1 vs. *one* PRP. The bounds are different (higher) if you consider saving two LL tests vs. one PRP.

Also, in general, lower TF makes worth it higher P-1 bounds, which is somewhat counter-intuitive. (i.e. the higher the TF, the lower the P-1 bounds that are worth it).

Edit: empiric is now 4/111 :)

[QUOTE=preda;513148]The theoretical probability of finding a factor (according to mersenne.ca) with those bounds is 2.16%, empirically I see 3/110. At this rate, and time per test, it is worth doing the P-1 vs. *one* PRP. The bounds are different (higher) if you consider saving two LL tests vs. one PRP.

Also, in general, lower TF makes worth it higher P-1 bounds, which is somewhat counter-intuitive. (i.e. the higher the TF, the lower the P-1 bounds that are worth it).

Edit: empiric is now 4/111 :)[/QUOTE]P-1 should be done to bounds maximizing total run time savings for TWO primality tests. (~2.04 for LL; 2 for PRP) Both LL and PRP are being subjected to verification by DC.

[QUOTE=SELROC;513132]you are right, I should try with amdcovc, another gpu monitor program.[/QUOTE]


but amdcovc with ROCm doesn't give utilization percentile. Retrying with radeontop...

[QUOTE=kriesel;513151]P-1 should be done to bounds maximizing total run time savings for TWO primality tests. (~2.04 for LL; 2 for PRP) Both LL and PRP are being subjected to verification by DC.[/QUOTE]

I'm not convinced of the need of 2 tests/exponent for PRP with GEC. I think the result is extremely reliable, and the double-check is needed only to detect intentional fakes. Now in my own point of view I know that I'm not producing intentional fakes, so in my POV there is very little need to double-check my own PRP results.

Another factor is *when* the double-check should be done. E.g. if somehow we should choose to double-check all the PRP results but with a delay of, let's say, 20years or more -- I could agree to that (given the large delay).

As I get more results in the following days, I'll report the empirical factor ratio with the bounds I chose. (to see if, empirically, the bounds are "useful")

[QUOTE=preda;513147]Yes I'm aware of this bug. I did introduce it in the last commit, where the final stage-2 GCD is done in the background (i.e. overlapped with the next test), which is a useful optimization for quick P-1 tests; but yep the bug is annoying, I'll think about a fix.[/QUOTE]

The bug should be fixed now -- GPUowl will wait before exit when a backgroud GCD is pending.

[QUOTE=preda;513228]I'm not convinced of the need of 2 tests/exponent for PRP with GEC. I think the result is extremely reliable, and the double-check is needed only to detect intentional fakes. Now in my own point of view I know that I'm not producing intentional fakes, so in my POV there is very little need to double-check my own PRP results.

Another factor is *when* the double-check should be done. E.g. if somehow we should choose to double-check all the PRP results but with a delay of, let's say, 20years or more -- I could agree to that (given the large delay).

As I get more results in the following days, I'll report the empirical factor ratio with the bounds I chose. (to see if, empirically, the bounds are "useful")[/QUOTE]
The persons setting GIMPS standards seem to be convinced of the need for double checking. And bad PRP/GC results have occurred and been detected. Software bugs happen. It's unlikely they've all been found in any given GIMPS application. Some of them happen outside the PRP/GC check capability.

I'd like to see the multiyear gap between first and second primality test reduced, not increased.

[QUOTE=kriesel;513237]The persons setting GIMPS standards seem to be convinced of the need for double checking. And bad PRP/GC results have occurred and been detected. Software bugs happen. It's unlikely they've all been found in any given GIMPS application. Some of them happen outside the PRP/GC check capability.
[/QUOTE]
Yes I agree in general about the need to check and find errors, but requiring a full 2x double-check seems overkill for PRP.

[QUOTE]
I'd like to see the multiyear gap between first and second primality test reduced, not increased.[/QUOTE]
In abstract yes, but at what cost? if given the option of using the next 1y for either finding the next MP, or closing the DC gap, the choice is not so obvious anymore.