[QUOTE=storm5510;530999]By security code, I take it that you mean the assignment ID?[/QUOTE]No. By security code, I meant the prime95/mprime generated security code in the result. Different field entirely. The source code for the rest is available, but not for that. Only mprime or prime95 results can have the security code field. The AID is merely repeated from input to output. The security code's value depends on the software and on the calculation, in a way that's unclear, but provides a way of checking whether there is a discrepancy. A completely fictitious res64 could be submitted with a valid AID in other applications, but the security code in mprime or prime95 results would reveal the fraud, when checked at the primenet server.

[QUOTE]If this is the case, [I]gpuOwl[/I] might include an AID in its results, if there is one present in the work assignment.[/QUOTE]GpuOwL DOES use an AID in its results.[QUOTE]It uses a rather different results format than anything I've seen before. It has a name, I know, but I cannot remember it at the moment.[/QUOTE]JSON.[QUOTE]
Some GPU applications do not pass through an AID when one is present in the work file.. I feel this needs to be corrected. Specifically, [I]mfaktc[/I], [I]CUDAPm1[/I], and [I]CUDALucas[/I]. Sorry for going a bit off-topic...[/QUOTE]Partly true, partly false.

All the following include AID in their result output (if one is present in the worktodo entry):
[B]CUDALucas v2.06[/B]
[B]CUDAPm1 v0.20[/B]
gpuowl of many versions
cllucas v1.04
mprime/prime95

These do not put the AID in the result record:
mfaktc
mfakto

(I have no results yet for mlucas)

[QUOTE=kriesel;531022](I have no results yet for mlucas)[/QUOTE]

From a recent DC result in Mlucas 18.0 :
[C]M51318853 is not prime. Res64: FA4E8EBD90893264. Program: E18.0. Final residue shift count = 21868454[/C]
So, no AID, at least not yet. (I'm including the full residue since it's been double checked and it appears in full on the mersenne.org exponent lookup as well.)

[QUOTE=kriesel;531022]No. By security code, I meant the prime95/mprime generated security code in the result. Different field entirely. The source code for the rest is available, but not for that. Only mprime or prime95 results can have the security code field. The AID is merely repeated from input to output. The security code's value depends on the software and on the calculation, in a way that's unclear, but provides a way of checking whether there is a discrepancy. A completely fictitious res64 could be submitted with a valid AID in other applications, but the security code in mprime or prime95 results would reveal the fraud, when checked at the primenet server.

GpuOwL DOES use an AID in its results.JSON.Partly true, partly false.

All the following include AID in their result output (if one is present in the worktodo entry):
[B]CUDALucas v2.06[/B]
[B]CUDAPm1 v0.20[/B]
gpuowl of many versions
cllucas v1.04
mprime/prime95

These do not put the AID in the result record:
mfaktc
mfakto

(I have no results yet for mlucas)[/QUOTE]

Ah! This is a security code: [B]Wh4: 12E068A0. [/B]I've only seen this with [I]Prime95[/I]. I know nothing about [I]Mprime[/I] as I do not do [I]Linux[/I].

Please forgive my error regarding [I]CUDALucas[/I] and [I]CUDAPm1[/I]. I must not have ran anything with them which had an AID. An old saying about "assume:" It makes an a** out of you and me.

JSON. Hit me on the head with a mallet. :blush:

[QUOTE=storm5510;531034]Ah! This is a security code: [B]Wh4: 12E068A0. [/B]I've only seen this with [I]Prime95[/I]. I know nothing about [I]Mprime[/I] as I do not do [I]Linux[/I].

Please forgive my error regarding [I]CUDALucas[/I] and [I]CUDAPm1[/I]. I must not have ran anything with them which had an AID. An old saying about "assume:" It makes an a** out of you and me.

JSON. Hit me on the head with a mallet. :blush:[/QUOTE]Wh4 is a compact version identifier.

[QUOTE=kriesel;530984]That's ok for wavefront PRP & P-1 on fastest gpus (Radeon VII). The 100M digit exponents or higher, or ordinary gpus are another matter. On an RX480, one PRP of 333M is 68 days, one P-1 to 2-tests-saved bounds is 2.2 days. On an RX480, 2-test-saved bounds P-1 of 102M is 4hr 15 min. On an RX550, it will be about 3.5 times that, around 16 hours for 102M P-1, and would be 7 to 8 days for 333M P-1.
Your time to spend how you see fit, of course, including beach vacations.[/QUOTE]
:goodposting::iws:

[QUOTE=nomead;531026]From a recent DC result in Mlucas 18.0 :
[C]M51318853 is not prime. Res64: FA4E8EBD90893264. Program: E18.0. Final residue shift count = 21868454[/C]
So, no AID, at least not yet. (I'm including the full residue since it's been double checked and it appears in full on the mersenne.org exponent lookup as well.)[/QUOTE]Thanks! Would you please also run a small known prime that would be quick? Perhaps

756839

[QUOTE=kriesel;531078]Thanks! Would you please also run a small known prime that would be quick? Perhaps

756839[/QUOTE]

Well... there, Mlucas works a bit differently.

First, in normal use, it has a table of known Mersenne primes and will report any re-test as such.

But after modification of the source and recompilation, it still behaves differently. There is no output on results.txt. But the tail end of the p756839.stat file states that
[C]M756839 is a new MERSENNE PRIME!!![/C]
and the program exits with the same message. The same happens whether it's a Test= or a DoubleCheck= line in the worktodo.ini file.

[QUOTE=nomead;531113]Well... there, Mlucas works a bit differently.

First, in normal use, it has a table of known Mersenne primes and will report any re-test as such.

But after modification of the source and recompilation, it still behaves differently. There is no output on results.txt. But the tail end of the p756839.stat file states that
[C]M756839 is a new MERSENNE PRIME!!![/C]
and the program exits with the same message. The same happens whether it's a Test= or a DoubleCheck= line in the worktodo.ini file.[/QUOTE]Thanks again. I'm incorporating it into a list of result formats that's now a draft but will eventually be a reference post in [URL]https://www.mersenneforum.org/showthread.php?t=24607[/URL]

I have been doing some off-and-on work for [B]James Heinrich[/B] on his project. He has helped me with questions in the past so I feel I should return the favor. He has a sub-project relating to poorly factored P-1 exponents.

Earlier, I took a few from his list, and pasted them into [I]Prime95's[/I] worktodo file and started it. Doing this assigns AID's to all the available exponents. The ones which do not get AID's I delete from the list. I have ran them in the form below and had no problems for close to a week:

[CODE]B1=600000,B2=8500000;PFactor=FFAABAF0706FF9F306F07524FA6A949F,1,2,91538501,-1,77,2
[/CODE]This morning, it was ignoring everything in my work file. I sat here over an hour, then I saw it; "P[COLOR=DarkRed]f[/COLOR]actor" where it should have been "P[COLOR=darkred]F[/COLOR]actor." [I]Prime95[/I] did not see this difference as a problem. I made a notation in a document in the folder to change these by hand. As for [I]gpuOwl[/I], trying to accommodate for this may not be worth the effort.

[QUOTE=storm5510;531569]This morning, it was ignoring everything in my work file. I sat here over an hour, then I saw it; "P[COLOR=DarkRed]f[/COLOR]actor" where it should have been "P[COLOR=darkred]F[/COLOR]actor." [I]Prime95[/I] did not see this difference as a problem. I made a notation in a document in the folder to change these by hand. As for [I]gpuOwl[/I], trying to accommodate for this may not be worth the effort.[/QUOTE]

Same here for gpu72, slightly annoying and I feel like it's not something I really need to do at all...

Had an error in a gpuowl v6.11-9 P-1 run:
[CODE]2019-11-27 13:03:48 Exception NSt10filesystem7__cxx1116filesystem_errorE: filesystem error: cannot rename: File exists [C:\Users\ken\Document
414000187\414000187-new.p2.owl] [C:\Users\ken\Documents\v6.11-9-g9ae3189\414000187\414000187.p2.owl]
2019-11-27 13:03:48 waiting for background GCDs..
2019-11-27 13:03:48 Bye[/CODE]